1

(7 replies, posted in Amiga)

Hi yoli,

Some time has passed since I played with it. Not really sure whats going on there. All I can say, I had this message once, just after copying stuff on the partition. Then I started over from scratch and it never happened again.

You also find some Google hits on this, like this:
http://eab.abime.net/showthread.php?t=6 … ;styleid=4

What I would try:
take a second fresh copy of the boot hdf. boot you Workbench with both images attached, do a

> copy source:#? destination: all clone quiet

style copy command to copy all files to the fresh image

2

(187 replies, posted in C64)

Cool thing wink Didn't know that. But now as you say it, yes also Hard'n'Heavy had that, even with the nice scroll trick

3

(4 replies, posted in C64)

Thanks (again?) for this core, I really appreciate having more options for c64 games wink

I just tried Katakis on your core, not the easiest candidate, I guess.

The game comes with an integrated fastloader and it is known to be unstable in terms of timing, cheat pokes etc. The original versions even erase the disk if a copy is detected.

There are 3 different official versions of this game, and a lot of cracks, including newer ones with improved emulator compatibility.

I have tried "Katakis V1 / Emulators +4" which allows to disable the fastloader.

This version runs perfectly, including fast loader, up to the point where the first boss appears. Seems that the collision detection is not working there. The boss should flash with every hit, but I can hardly make him flash once in the given time. (I checked the youtube longplay to see how it should work)

c64 core by WoS hangs/crashes at random positions , e.g. just after the main menu. I did not make it to the first level with a few attempts. Interestingly, this is independent from the fast loader setting. Fast loader seems to be working well here as well.

Then I tried another version of the game: "Katakis V2 Cyberpunx +5".
This is interesting, as it might be fixable easiliy. both cores, your cc64 and the WoS core, have the same issue: I cannot start the loader prg. After LOAD "*",8,1 and RUN, I just get a READY. First I thought its the image, but it's working well on Vice.

SDCard used is a SanDisk Ultra 80MB7s SDHC, 32GB

4

(187 replies, posted in C64)

Actually, it was my fault, I used the 720p version, not 576p. Still, thanks for your fast support, I really enjoy the game.

Btw: is the 720p version working over dvi/hdmi?

5

(187 replies, posted in C64)

Yes you're right. The PAL core plays it without glitches.

Still, I have some issues with the video timing, which could very well be my monitor.
Using your core, only 60% of the screen width is used, compared to what I would expect. (see the image attached)

This is especially a problem as my monitor has no options to scale the image, just position can be adjusted.

Not sure if this is clearly the "fault" of your core, not with my monitor, but at least the picture is fine with other cores.

Nevertheless, is is great already to have your core available!!

6

(187 replies, posted in C64)

Just gave it a try. I tried your latest core cc64_9-8-18.zip, but I didn't see a specific PAL version/option. Maybe I missed it?

Basically, it is running on both cores, c64 and cc64, with different issues:

c64: visually quite perfect compatibility, only the SID emulation's weak spots are exposed, triggering my tinnitus in a really hard way

cc64: as I said, don't know, if I have the PAL setup running. Image is way to narrow/long on my monitor (which has no option to compensate) and I have sporadic minor graphic glitches (due to ntsc setup?). Still its by far the more playable version if you want sound.

The game itself is really outstanding. In some ways, it is just too elaborated for a C64 game, giving it an unreal feeling. But I can 100% recommend it to anyone interested in 64 gaming.

Btw, I am still wondering how it works technically, they seem to mix hires (320x...) with lowres (160x...) backgrounds, aren't they?

7

(187 replies, posted in C64)

That's cool wink so I guess I know what to play next... Will let you know how it works out.

Did you run the disk or the module version?

8

(187 replies, posted in C64)

Has anyone tried to get Sam's Journey running? (https://www.knightsofbytes.games/samsjourney)

looks really great, but I hesitate to buy it as long as I am not sure it works

9

(9 replies, posted in C64)

One I can remember was R-Type. This was rather in the game itself than in the loading phase. The system was completely freezing, somehow related to joystick input. Also I never got Katakis to run, this was rather a loading issue.

To be honest, I should be a bit more careful here: I used an SD-Card which had no approved SanDisk branding. (But it did work well with Amiga cores for long time, until a certain Firmware Upgrade.) Maybe the wrong sd card can even trigger in-game load errors?

However, I tried around 20 of my favourite C64 games and the ratio of working titles was way below 50%. Somehow I lost interest in the whole thing, as there was never progress for any core except Amiga.

I reported some issues here:
http://www.fpgaarcade.com/punbb/viewtop … 5708#p5708


Is this just my exerience? Did anyone try, lets say 10-20 more complex C64 games (in-game loading, tricky VIC usage..) and found the majority of them working?

10

(9 replies, posted in C64)

From what I experienced, the C64 core still has a lot of issues. I hardly managed to run any late C64 games at all. Nothing has changes about this in the last years, so I do not have much hope here.

A test bench could probably help if it points to bugs which are easily locatable, but my feeling is that most issues are with the floppy code (games usually hang up while loading), and this test bench does not seem to have a focus on floppy emulation.

@erique I just flashed July2017 before

@grandalf thanks, although this is not quite the answer I was hoping for. Look at the image (left card) - this is definitly not a cheap, slow card. (Actually the cheap slow card on the right is the one which is working now.) However, I remember now that Mike wrote, we should use Sandisk, and I didn't, so it is fair not to count this as a bug.

It is really the card and not my setup. I didn't use any HD partitions at all, its the loader and the updater which is not working - and yes the same files work on the cheap card.

The expensive card used to work for years now. My first idea was that the new core has a problem with bigger capacities. But I guess I am now the only one with an 32 GB card.

I just installed the Oct2017 Firmware, and now my sdcard normally used for replay (left on photo) cannot be read anymore. After a few minutes of a black screen, I get the error in the attachment.

Another, small cheap sdcard (right on photo) is working fine though.

Don't know if this is related, but I had issues before when using an SD-Card slot extension cable  (No logic involved, just wires). Probably all of this is somehow timing related.

I don't think this is required. For me this rather sounds like a talking point to convince people who do not understand the benefit of FPGAs over emulators right away.

Just my opinion.

(Still, I am really looking forward to get my Super NT)

14

(28 replies, posted in Amiga)

@Belial6: Its not about being "more precious". Its one core concept in IT and computing: Multi-layer architectures. You always have lower levels doing fundamental stuff (being agnostic about high level applications), and high level application-specific code, which is not allowed to mess up the low level stuff directly.

On PCs, applications are not allowed to write to kernel memory, to talk to hardware directly without the kernel, to write blocks on the disk without using the filesystem...

Of course, these concepts weren't that strong back in the old days with AmigaOS smile

Still, these access scheme is possible and you might never face any issued with it, but its clearly bad practice.

15

(28 replies, posted in Amiga)

Depends on your backup strategy... copying a hdf file is more simple than a block-wise representation of your sdcard.

Plus, your Amiga core can break other cores' setups with this.

16

(28 replies, posted in Amiga)

Belial6 wrote:

I am trying to understand the danger of allowing access to the SD card.

Two things:

1) Amiga Software should be considered "rather buggy". No as in "poorly written", but Amiga is our sandbox to play inside. We do possibly crazy stuff there. The core might have bugs. And also, Amiga OS did not have memory protection - crashes should be expected more often than in modern systems.

Crashes might result in data corruption on the disk. With this access scheme, an Amiga crash could corrupt the loader files, i.e. a bug could "break out" of the simulated system.

When only a disk image file is mounted, corruption by Amiga SW crashes can only affect Amiga files.

2) The loader might - in theory change something on the filesystem at the same time the Amiga does it. This could result in corruption. But, normally the loader should be inactive once the core is running.

17

(28 replies, posted in Amiga)

Anyone tried to have two partitions on the sdcard, so that firmware loader files and other systems' images are not mixed with the Workbench files?

SDcards, as USB sticks are normally formatted in "SuperFloppy" format, with no real partition table. If you create a partition table on your SDCard, Windows will only mount the first partition, as long as you dont use some further tricks.

I guess the main problem would be the loader not to rely on SuperFloppy format, right?

18

(42 replies, posted in General discussion)

@MikeJ: This is a nitpicking side discussion - But a Rasp Pi is technically a "complete computer" - I do not see a fundamental difference compared to using a i7 Kaby Lake PC as "compute board". (Could be connected to a host PC as a graphics adapter is, but still containing the fully independent Amiga System - PCIe is flexible enough to act like the daughterboard IF, I guess)

But still it was just a joke wink

19

(42 replies, posted in General discussion)

This is really a funny development, chasing after the fastest possible Amiga wink Just hallucinating, what could come next.... What about an PCIe graphics card, fully compatible to the AGA chipset?

20

(24 replies, posted in Other platforms/cores)

Hopefully I do not start an emotional discussion  here wink

What I mean is: Amiga, C64, vintage consoles, arcade hw etc. are programmed tightly around the HW timing. Programmers synchronized the execution time of commands with the speed of the video signal.

You normally do not have that in the PC world. PCs always had different speeds (there was the one first IBM PC, but it wasn't so dominant).

Also, there were only very few smooth 2D scrollers with exactly 50/60 fps on the PC.

There is not *the* single PC timing which is important to have an authentic experience of a game. Start Up a VM, or even an emulator, and the game will feel as original as in the past. At least for my personal perception.

The difference emulation/FPGA was striking for me on the Amiga. I would not expect this for pc games.

21

(24 replies, posted in Other platforms/cores)

For retro gaming I really don't get the point here. PC games never were bound to exact timing of components(*), there have always been slower and faster PCs. So you still get the same experience with your current PC, and maybe a virtual machine if needed.

(*) The only exception I know of:
https://trixter.oldskool.org/2015/04/07 … emulators/

Still it would be a cool technology demo to have a 486 running on the replay, but it does not add benefits to my gaming experience. Also there is an issue with joystick ports vs PC analog joysticks...

22

(43 replies, posted in Amiga)

There is a 4gb limit for files on the fat-formatted sd card.

We discussed this already once.
Changing this would require to implement another (more complex) file system on the microcontroller.

Other option would be support for splitted image files on fat system.

However 2x4 GB seem to be pretty sufficient for me.

23

(6 replies, posted in Troubleshooting)

For the black screen on Galaga, dont underestimate the possibility of mismatches in rom file names vs ini file. Especially look at "_" vs "-" and similiar.

24

(12 replies, posted in Amiga)

RTG is an additional framebuffer. Think of something similiar to an VGA Graphics Card soldered to your Amiga. It does not use any of the old OCS/AGA control registers for sprites/scrolling/etc. It has probably new ones, though.

(Take this as a first rough idea, I am not an expert on this)

If I may add a feature request here...

In the end, it would also be cool to have a kind of kiosk mode, where the loader only shows a single menu to select from a list of cores (so that only up, down and return keys are needed). This would be cool to demo stuff and let people play without explaining too much.

Full menu could then be reached by pressing a certain key