Kickstart 1.2 InitResident() booting issue.

[bloodline]

Hi All,

As you know I've been trying to get Kickstart 1.2 booting on a 68k Emulator with minimal custom hardware support... Now the os boots fine to the InitCode(), then it enters the InitResident() function. Now I've stepped (painfully slowly) through the libraries and devices being loaded:

expansion.library
audio.device
intuition.library

Then it tries to load the mathffp.library... it enters the AddLibrary() function and never returns... not sure what's going wrong here... any ideas?

[Minuous]

There issue would be in the library's initialization routine rather than in AddLibrary() itself.

Maybe it's trying to detect an FPU? You'll probably need to disassemble the library's initialization routine. Or looking at the relevant 3.1 source code might be helpful, depending on how much was changed between 1.2 and 3.1.

[bloodline]

Originally Posted by Minuous

There issue would be in the library's initialization routine rather than in AddLibrary() itself.

Maybe it's trying to detect an FPU? You'll probably need to disassemble the library's initialization routine. Or looking at the relevant 3.1 source code might be helpful, depending on how much was changed between 1.2 and 3.1.

That's the question, does mathffp try to detect an FPU? If so then I need to understand how it tries to do that and let it know no FPU is available. I assumed it would check exec, which should by this point known there is no FPU.

[bloodline]

Ok, so I decided to dump the disassembly from the point after mathffp is added to the exec library list to disk... the result after about a minute was a 2.5Gb text file (I've zip compressed it down to a few meg- available here: https://drive.google.com/open?id=1tr...IQ041n0oYslNLe if you want to have a look), and it appears that mathffp does load properly, it is whatever try to load next which fails... perhaps some library or device which is trying to hit the (non existent) hardware?

-edit- it does seem to spend a lot of time in the allocmem function... something (some device?) is allocating a lot of ram...

Ok, after spending the last few hours stepping through the code, whatever device is being started, it seems to be stuck in some kind of loop perhaps waiting for some piece of hardware to respond correctly... How did the Draco guys boot AmigaOS without real hardware?

My guess is the floppy drive (CIAA->pra is read quite a bit)... which suggests the device in question is the trackdisk.device... I guess I need to write some kind of proper floppy drive emulation...

Its seems to go through a loop of selecting and then unselecting drive 0... Since it never turns the motor on... I'm not sure what it is expecting.

[bloodline]

I think I figured it out, when the OS selects drive 0, it then steps the head... at which point the disk change signal in CIA A needs to be set high... that took a whole day

Now let's see how far we get.

-edit- so now it writes to the dskpth and dskptl registers... and once again becomes stuck in a loop... now I need to figure out what else the hardware does...

[bloodline]

For those playing along at home, I'm now trying to understand what the OS is doing from ROM location 0xFEA558 onwards.

-Edit the first thing it does is disable the DSKBLK and DSKSYN interrupts (which doesn't currently matter since I don't emulate them).

[mark_k]

It clears the disk block and disk sync bits in intreq (not intena), then it enables disk block interrupt, then writes to dsklen to start disk DMA. You need to generate an interrupt when disk DMA is complete.

[Toni Wilen]

You also need to implement blitter if you want working disk access. Disk MFM decoding uses blitter under KS 1.x. And CIA timers need to work. And..

[bloodline]

Originally Posted by mark_k

It clears the disk block and disk sync bits in intreq (not intena), then it enables disk block interrupt, then writes to dsklen to start disk DMA. You need to generate an interrupt when disk DMA is complete.

Thanks for the clarification, to progress I am going to need the disk interrupts working!

I also see that I think I have the floppy drive initialisation sequence wrong...

[bloodline]

Originally Posted by Toni Wilen

You also need to implement blitter if you want working disk access. Disk MFM decoding uses blitter under KS 1.x. And CIA timers need to work. And..

My plan... such that it is, is to get just the most minimal parts of the hardware emulated to get to the KS1.2 boot screen. Then I will try the same for KS3.0... hopefully then I can implement the Gayle IDE and do actual OS booting via that... hopefully avoiding the need for real floppy decoding.

My end goal is to have a tiny 68k (+some amiga bits) emulator I can use as "firmware" on the Raspi... I hope to bring this in under quarter of a megabyte.

This is never going to be UAE

[mark_k]

Originally Posted by bloodline

I think I figured it out, when the OS selects drive 0, it then steps the head... at which point the disk change signal in CIA A needs to be set high... that took a whole day

If you don't care about getting further than the insert WB screen, shouldn't you have the disk change (ciaapra bit 2) always be 0? Otherwise the Amiga thinks a disk is inserted and will try reading from it.

[bloodline]

Originally Posted by mark_k

If you don't care about getting further than the insert WB screen, shouldn't you have the disk change (ciaapra bit 2) always be 0? Otherwise the Amiga thinks a disk is inserted and will try reading from it.

You are correct, I have fixed that now. And the emulator just got itself stuck in a look at address 0xFC5A04 testing bit 6 of DMACONR... which was set (Blitter on)... so I set bit 6 to off and now the blitter registers are being written to like crazy...

Why does the CPU want to know if the blitter DMA is not enabled? Does the blitter automatically clear that bit when it completes? shouldn't the OS test for the blitter busy flag? I really don't understand.

[Toni Wilen]

Hint: it uses byte wide instruction to check it, it is not checking actual bit 6

[bloodline]

Originally Posted by Toni Wilen

Hint: it uses byte wide instruction to check it, it is not checking actual bit 6

I've been using little endian machines for too long... I forgot about that.

-edit- Byte reads from the chipset regs happen a lot ... Since I never handled them properly before, I'm surprised I got as far as I have. I only byte swap for chip ram access, so I have to have special case read and write functions for non word custom chip register access.

[bloodline]

Ok... So we have reached the point where Drive Head 0 is stepping every 16 seconds... which suggests that the trackdisk.device is up and running (doing it's famous "drive click")... but something is still wrong... no copper list is set up and the bitplane pointers are never set.

I decided to simulate the Blitter (I hold the blitter busy-bit high after a write to bltsize, and counts down to 0, clears the bitter busy-bit and then sets the blitter intreq flag), this was to appease the blitter wait loops in the code.

-Edit- the copper is working, I think my wait instruction is not implemented correctly... the bitplane pointers are updated and point to the correct memory location (when compared with ActionReplay info command on a 1.2 booted A500), but examining the memory contents shows nothing has been loaded there. Since the image would need to be loaded from ROM I assumed it would be copied by the CPU not the Blitter?

[bloodline]

So after some fiddling I notice that there is some junk being written to the bitplane memory... since there is a lot of Blitter activity during boot, I decided to implement some of the blitter, and have a rudimentary block copier (have not bothered with the shifting, but minterms and modulo's are there)... I have now notice that a large amount of the blitter activity is actually with (BLTCON1 & 1 ) == 1 so I guess the kickstart screen is largely drawn by the blitter... I'm going to have spend a bit of time seeing if I can implement the line drawing algorithm... not what I had intended to do, but this is really good fun!

[nogginthenog]

This is really interesting - keep up the good work!
The next Amithlon maybe

[bloodline]

Originally Posted by nogginthenog

This is really interesting - keep up the good work!
The next Amithlon maybe

Hopefully someone will find it useful, but currently it runs about one the tenth the speed of a real A500 (due mostly due to CPU execution currently being locked to the screen update).

Honestly, with the power of modern hardware now, nothing is going to beat UAE for features and performance. Toni etc have done an amazing job with that. Amithlon made a lot of sense when the host machine was 32bit, now all machines are 64bit, it kind of makes more sense to keep the Amiga stuff locked away in the Emulator.