Baremetal Amiga Emulator

[pixie]

We now have emu68k

[pandy71]

Curious if this https://github.com/FEX-Emu/FEX can be beneficial for MC68k emulation on ARM.

[bloodline]

Thread necromancy!

Or more accurately a project update… As my Analytical work on COVID-19 is winding down, I’ve had a chance to do some much needed clean up on the Emulator project.

In reality so much has changed it’s really more of a rewrite to avoid all the poor design decisions I made at the beginning notably the memory system. Anyone who has taken the time to look at the source will see what a mess it is. Every time I tried to clean it up, the emulator broke, so it just grew into an unmanageable mess of hacks and kludges.

The new system works using a central despatch function to direct the memory requests to the correct system, it’s far more elegant and has allowed a cleaner overall architecture. It was definitely worth taking the time to put it right.

That’s the good news… The bad news is that while I can get Kickstart 1.2 to boot, I’m again (I recall having this same issue when I started the project) faced with the issue that the Copperlists seems to be writing Zeros into the BLPxT registers… so I can’t get the display working. I wish I had made more detailed notes as to the problem last time. Long nights of debugging ahead…

FYI, pretty much only the Blitter code has remained intact from the earlier part of the project (I will probably be reusing the Planar2Chunky code and the floppy emulation too)… and is currently awkwardly grafted into the new system, that might be causing issues!? No idea. I have just spent the day squishing some really nasty CIA bugs.

[bloodline]

After a night of debugging… I’m still no nearer to understanding what is going wrong. This morning I have wondered if there might be a problem with my address decoding and perhaps, something is being overwritten in memory… I guess that is tonight’s tasks to investigate.

-Edit- To clarify, for those following at home… Some reads and writes are not symmetric at certain addresses… the trick seems to be finding them…

[skan]

Great to know you're back on this cool project!
I still think this + emu68 can only bring good things (read: BMA500/1200! )

[bloodline]

Originally Posted by skan

Great to know you're back on this cool project!
I still think this + emu68 can only bring good things (read: BMA500/1200! )

Well quite a few of my original design decisions were based on the idea that I wanted to run the emulator on relatively low powered ARM cores (read Teensy 3.1)… which in hindsight was probably a cases of “optimising too early”. Not targeting such a low performance host makes for much nicer source code

I still can’t get any of the Kickstart ROMs to generate a valid display… but John Hartell’s DiagROM from 2017 boots fine (weirdly his latest one doesn’t), so that’s what I’m using to debug at the moment

[bloodline]

So after much debugging it’s clear my old nemesis is back… The floppy drive.

Kickstart 1.3 goes through what appears to be the correct behaviour, it starts by detecting DF1, Turning the Motor on and off to clear the ready flag, and then proceeds to pulse the select line until the drive flags the ready signal (my emulated floppy drive waits 32 pulses)… the Kickstart then selects DF2, motor on, then off to clear the ready flag and pulses the select line, the same for DF3… so far so good. But then it just selects DF0, no motor action, pulses the select line 6 times, turns the motor on, steps the head up a track then back to Zero and the whole thing just locks up…

Too late to investigate now… that will have to be tomorrow night’s session

[hooverphonique]

There is no ID stream from DF0, it is just assumed to be there by all kickstarts..

[bloodline]

Originally Posted by hooverphonique

There is no ID stream from DF0, it is just assumed to be there by all kickstarts..

Ok… So that means the kickstart behaviour is likely correct, with the last two head steps being the disk detection… which don’t continue due to a crash…

Stepping through the assembly suggests Exec is crashing while trying to AddResouce()… it must be looking for something in the address space which I haven’t accounted for.

My old memory mapping code was an absolute Spagetti mess, where I tried to trap various addresses (added just to get Kickstart booting). I’m struggling to follow what it was actually doing, hence why I rewrote it.


-Edit- So I hadn't cleared The DISKCHNG bit, the heads (of DF0) are stepping normally. The problem is with some other system...
I can also see that something executing at around 0xFCC150 in KickStart 1.2 is filling the up ChipRam...

-Edit Which appears to be the KickStart hand image drawing code... Maybe my Blitter is not working right? The line draw seems ok, but it seems to be looping around lots of small blits....

[paraj]

$fcc150 is inside graphics.library, and seems to be used in connection with blitting, so that seems plausible (If you haven't seen it already this stackoverflow post details how the image is drawn).

BTW I have a crude semi-automatic disassembly of KS1.2 that I can share if you like, PM me if you want it.

[bloodline]

Originally Posted by paraj

$fcc150 is inside graphics.library, and seems to be used in connection with blitting, so that seems plausible (If you haven't seen it already this stackoverflow post details how the image is drawn).

BTW I have a crude semi-automatic disassembly of KS1.2 that I can share if you like, PM me if you want it.

Cheers! That confirms what I have found… since my Blitter code worked fine on the previous version of the emulator (and passes the tests in John Hertell’s DiagROM), we assume that it and the graphics library are working fine. It must be the boot code which is calling the library which has wrongly identified the memory map… almost certainly due to incorrect address space decoding by my new memory dispatcher

-Edit- @paraj your account is set to not receive PMs

[bloodline]

I have now tested the whole 24bit address space, and it seems my address decoding is correct… the only special handler is for the Slow RAM space where it shadow the custom chip registers so the Kickstart doesn’t try and map any slow RAM.

So that can’t be the problem… I’m wondering if my CIA timers are at fault? How to test them!?

[paraj]

(PM issue should be fixed, but I've sent you a message).

DiagRom IRQ/CIA tests aren't conclusive, but provide good feedback. They don't need to pass (timing can be very off and KS will still work), but they shouldn't hang.

[bloodline]

Originally Posted by paraj

(PM issue should be fixed, but I've sent you a message).

DiagRom IRQ/CIA tests aren't conclusive, but provide good feedback. They don't need to pass (timing can be very off and KS will still work), but they shouldn't hang.

Well, I’ve run as many tests as I can to check the CIA code is running as expected…

But trying to track though the running code it’s obvious that the Kickstart is getting stuck in some kind of loop while trying to draw the “Insert Disk” screen… but trying to figure out exactly what is going on is very difficult (made more so by the interrupts, which obviously pop into the instruction stream… I think I know the interrupt despatch code off by heart now).

[hooverphonique]

I should clarify my statement:

No ID stream from DF0 is only true in case of a 3.5" DD drive - maybe that's why the kickstart pulses select a few times to check if anything (special) is there..

[bloodline]

Originally Posted by hooverphonique

I should clarify my statement:

No ID stream from DF0 is only true in case of a 3.5" DD drive - maybe that's why the kickstart pulses select a few times to check if anything (special) is there..

That’s interesting, since I’ve only ever used 3.5” I was unaware other drives did anything different!

[bloodline]

As an experiment, I filled the full 16meg address with 0xFF. My code initialises the space where the custom chips live and the CIAs, the ROM space obviously contains the ROM… I’ve also set the whole autoconfig space to 0x0.

Now when I run the emulation, kickstart crashes during setup… I’m trapping all read and writes to memory areas where nothing resides… So how can it be going wrong… I’m really confused.

-Edit-
This is the problem I had with the memory system before… But the time the emulator worked, it had become an unstructured mess of conditionals, cases, and masks… Which more by luck than design, accidentally worked.

I guess I need to think this through again

[hooverphonique]

Originally Posted by bloodline

That’s interesting, since I’ve only ever used 3.5” I was unaware other drives did anything different!

See http://amigadev.elowar.com/read/ADCD.../node0111.html


Kickstart 2+ also supports HD 3.5" drives (with a different identification) -these were mainly used in A3000/A4000, but also work in other amigas.

[bloodline]

Originally Posted by hooverphonique

See http://amigadev.elowar.com/read/ADCD.../node0111.html


Kickstart 2+ also supports HD 3.5" drives (with a different identification) -these were mainly used in A3000/A4000, but also work in other amigas.

There are few documents as opaque as the Amiga HRM, but that does confirm a drive should hold the DSKRDY line low from when the motor is turned off until it receives 32 select signals or a motor on signal… at which point it should drive the DSKRDY signal high.

[hooverphonique]

Originally Posted by bloodline

but that does confirm a drive should hold the DSKRDY line low from when the motor is turned off until it receives 32 select signals or a motor on signal… at which point it should drive the DSKRDY signal high.

I have never seen a drive implementation which actually cares about the 32 bit count, they just keep clocking out the same pulse train as long as the motor is off. These are often done using a D-flipflop, given the pulse trains are so simple (FFFFFFFF, AAAAAAAA, 55555555). For an alternating stream, the flipflop needs to be set to the correct state when turning off the motor, of course.