Baremetal Amiga Emulator

[bloodline]

Originally Posted by jbl007

Works now, and I must say it's quite impressive.
I loaded some programs from my old tools disk, many of them work very well f.e. DirOpus 1.5, Cygnus Ed. II, BootX, Powerpacker...

XCopy Pro has wrong palette, no mouse pointer and host cpu is at 100%

I’ll need to investigate the palette issue (it could be using some copper trick to alter the palette)... and I haven’t profiled Omega yet so I don’t know why the CPU sometime goes to 100%! But I will look into it! Not surprised about the mouse pointer... see below...

It seems that programs using overscan screen do are not displayed correctly. Is this a known problem? For example VTSchutz and Scene Generator. Screen is trashed and mouse pointer warps around (if moved to left it appears of the right)

Omega doesn’t support overscan, it was an early design decision as I want to prioritise running OS legal apps over games at this time. Adding support for over scan would be an easy and fun project (should anyone wish to do it, before I get around to it... I will need to overhaul the display generation at some point and will allow more display options... including PAL etc...).

BTW: Did you already notice: the mouse busy pointer Zzzzz is missing it's lower part of the bubble

Yup, sprites aren’t really emulated, Sprite0 has just enough features emulated to show the system pointer. Again my priority is getting the operating system working, so I really just need one sprite working right now.

-edit- cheers for the screenshot, what platform are you running Omega on?

[bloodline]

So it turns out Omega can boot kickstart 2.05 as ripped from one of my A600s...(this is good as this ROM will boot from the IDE) It doesn't show the kickstart screen, but that doesn't matter as it will boot a disk. But it doesn't recognise any disk image I provide it (Error: Not a dos disk in DF0.

I guess it wants to use the dsksync/adkcon registers... I haven't touched these before, so what is the OS expecting?

-edit- ok, after some reading, it look like I have to start the DMA transfer only when the sync mark is found? if so that sucks, and adds yet another layer of complexity to the emualtion

[Genlock]

Is this old post any use for you.
http://eab.abime.net/showthread.php?t=54267

joe

[Toni Wilen]

KS 1.x: does not use WORDSYNC (Apparently because Paula WORDSYNC support was implemented/fixed too late and they didn't want to touch already working floppy driver)

KS 2+: WORDSYNC is used.

[bloodline]

Originally Posted by Genlock

Is this old post any use for you.
http://eab.abime.net/showthread.php?t=54267

It’s not, but it is a fantastic thread! I could read Toni’s details of the Amiga chipset all day... Another hint at him writing a new HRM

[bloodline]

Originally Posted by Toni Wilen

KS 1.x: does not use WORDSYNC (Apparently because Paula WORDSYNC support was implemented/fixed too late and they didn't want to touch already working floppy driver)

I know how they feel...

KS 2+: WORDSYNC is used.

Yeah, and the sequence of events is now far more complex...

1. The drive motor starts
2. Comes up to speed and sets the rdy signal.
3. The drive starts reading the disk.
4. When 0x4489 is read, the dsksync INT is raised, and the wordsync bit in diskbytr is set.
5. Now the DMA starts to read, I assume it starts the next sync word after the first sync word... the Read happens as before, loading the whole track (and a some more) into memory then raising a diskblock INT.

So this is what I do... but it’s not working, trackdisk keeps writing to the dsksync register, which suggests it’s struggling to make sense of the data stream... have I missed a step?

Additionally, it seems that the dsksync interrupt isn’t enabled anyway... And the dskbytr register is never read.

I never though I would miss the KS1 trackdisk.device

-edit- Added a screenshot for those who are keen to see my emulator show it's first OS2 screen!

[Toni Wilen]

Originally Posted by bloodline

4. When 0x4489 is read, the dsksync INT is raised, and the wordsync bit in diskbytr is set.

Sync interrupt and DSKBYTR are not used by ROM loader.

5. Now the DMA starts to read, I assume it starts the next sync word after the first sync word... the Read happens as before, loading the whole track (and a some more) into memory then raising a diskblock INT.

Most common situation is that first sync marker is "eaten" but there is also chance that both or neither are transferred. (ROM code should handle all situations, some trackloaders don't handle it very well)

Word sync logic works like this:

Internal 4 bit counter is increased each time bit is received from drive to internal 16 bit shift register. When word sync matches: bit counter is reset and internal DMA enabled flag gets set.

Data is only transferred from shift register (in wordsync mode) if bit counter == 15 and DMA flag is enabled.

two markers: counter was already in sync (1/16 chance in real world, it is good idea to randomize or never sync it in emulation to keep compatibility with bad loaders)
one: first was not in sync
none: DSKLEN was written mid first sync marker (really tiny chance)

[hooverphonique]

Originally Posted by Toni Wilen

KS 1.x: does not use WORDSYNC (Apparently because Paula WORDSYNC support was implemented/fixed too late and they didn't want to touch already working floppy driver)

In this situation, the bitstream just comes in unaligned to byte/word boundaries, right? So you need to sift through the bitstream "manually" to find the sync words and thus how much shift is needed for alignment?

I suppose this is one of the reasons they used the blitter for decoding, so they could use the shifter to boundary-align the data.

[Toni Wilen]

Originally Posted by hooverphonique

In this situation, the bitstream just comes in unaligned to byte/word boundaries, right? So you need to sift through the bitstream "manually" to find the sync words and thus how much shift is needed for alignment?

I suppose this is one of the reasons they used the blitter for decoding, so they could use the shifter to boundary-align the data.

Yes and yes, at least it is most likely.

Bit stream comes in random "aligment",0 to 15 bit shift required to make it word aligned.

Blitter is most likely used because it has barrel shifter and shifting is always free. 68000 requires extra 2 cycles per bit shifted. (68020+ has barrel shifter)

[bloodline]

Originally Posted by Toni Wilen

Sync interrupt and DSKBYTR are not used by ROM loader.

Excellent, that explains why these don't trap! Many thanks.

Most common situation is that first sync marker is "eaten" but there is also chance that both or neither are transferred. (ROM code should handle all situations, some trackloaders don't handle it very well)

Word sync logic works like this:

Internal 4 bit counter is increased each time bit is received from drive to internal 16 bit shift register. When word sync matches: bit counter is reset and internal DMA enabled flag gets set.

Data is only transferred from shift register (in wordsync mode) if bit counter == 15 and DMA flag is enabled.

two markers: counter was already in sync (1/16 chance in real world, it is good idea to randomize or never sync it in emulation to keep compatibility with bad loaders)
one: first was not in sync
none: DSKLEN was written mid first sync marker (really tiny chance)

Ok, this makes sense and fits with my mental model... So my implementation must be doing something counter to this.

from your explanation it seems like it doesn't really matter if the sync mark is found. If the DMA loads the track into memory as it did for my OS1.x loader, it trackdisk should still be able to figure it out. Could it be an issue with my MFM emulation?

My virtual floppy drive just keeps "spinning the disk" (it's a ring buffer with the track in it so the index pointer just goes around and around), the DMA starts when a sync mark is found and then just loads the track into memory a word every DMA slot as it always has... The sync aware floppy emulation still works with OS1.x?!

I notice the OS2 trackdisk uses a smaller dsklen, but it is still bigger than a track of data, so it should work.

Also, OS2 write to BEAMCON0... but I have no documents for that register. No idea what the bit positions mean!

[hooverphonique]

Originally Posted by bloodline

from your explanation it seems like it doesn't really matter if the sync mark is found.

It shouldn't matter for trackdisk.device if there is 0, 1, or 2 sync words at the beginning of the dma buffer, yes (OS2+).

Originally Posted by bloodline

Also, OS2 write to BEAMCON0... but I have no documents for that register. No idea what the bit positions mean!

[CODE]
beamcon0 EQU $1dc ; Beam counter control register (ECS)
; (SHRES,UHRES,PAL)
15 -
14 ECS HARDDIS Disable Hardwired vert/hor blank
13 ECS LPENDIS Ignore latched pen value on vert pos read
12 ECS VARVBEN Variable vertical blank enable
Use VBSTRT/STOP disable hard window stop
11 ECS LOLDIS Disable longline/shortline toggle
10 ECS CSCBEN Composite sync redirection
09 ECS VARVSYEN Variable vertical sync enable
08 ECS VARHSYEN Variable horizontal sync enable
07 ECS VARBEAMEN Variable beam counter comparator enable
06 ECS DISPLAYDUAL Special ultra resolution enable
(use UHRES pointer and standard pointers)
05 ECS DISPLAYPAL Programmable PAL mode enable (pal/ntsc switch)
04 ECS VARCSYEN Variable composite sync enable
03 ECS BLANKEN-CSBLANK Composite blank redirection (out to CSY pin)
02 ECS CSYNCTRUE Polarity control for Composite sync pin (TRUE)
01 ECS VSYNCTRUE Polarity control for Vertical sync pin (TRUE)
00 ECS HSYNCTRUE Polarity control for Horiz sync pin (TRUE)

(From C-18 AGA DOC)

HARDDIS = This bit is used to disable the hardwire vertical horizontal
window limits. It is cleared upon reset.

LPENDIS = When this bit is a low and LPE (BPLCON0,BIT 3) is enabled, the
light-pen latched value(beam hit position) will be read by
VHPOSR,VPOSR and HHPOSR. When the bit is a high the light-pen
latched value is ignored and the actual beam counter position is
read by VHPOSR,VPOSR, and HHPOSR.

VARVBEN = Use the comparator generated vertical blank (from VBSTRT,VBSTOP)
to run the internal chip stuff-sending RGA signals to Denise,
starting sprites,resetting light pen. It also disables the hard
stop on the vertical display window.

LOLDIS = Disable long line/short toggle. This is useful for DUAL mode
where even multiples are wanted, or in any single display
where this toggling is not desired.

CSCBEN = The variable composite sync comes out on the HSY pin, and the
variable conosite blank comes out on the VSY pin. The idea is
to allow all the information to come out of the chip for a
DUAL mode display. The normal monitor uses the normal composite
sync, and the variable composite sync &blank come out the HSY &
VSY pins. The bits VARVSTEN & VARHSYEN (below) have priority over
this control bit.

VARVSYEN= Comparator VSY -> VSY pin. The variable VSY is set vertically on
VSSTRT, reset vertically on VSSTOP, with the horizontal position
for set set & reset HSSTRT on short fields (all fields are short
if LACE = 0) and HCENTER on long fields (every other field if
LACE = 1).

VARHSYEN= Comparator HSY -> HSY pin. Set on HSSTRT value, reset on HSSTOP
value.

VARBEAMEN=Enables the variable beam counter comparators to operate
(allowing diffrent beam counter total values) on the main horiz
counter. It also disables hard display stops on both horizontal
and vertical.

DUAL = Run the horizontal comparators with the alternate horizontal beam
counter, and starts the UHRES pointer chain with the reset of
this counter rather than the normal one. This allows the UHRES
pointers to come out more than once in a horizontal line,
assuming there is some memory bandwidth left (it doesn`t work in
640*400*4 interlace mode) also, to keep the two displays synced,
the horizontal line lentghs should be multiples of each other.
If you are amazingly clever, you might not need to do this.

PAL = Set appropriate decodes (in normal mode) for PAL. In variable
beam counter mode this bit disables the long line/short line
toggle- ends up short line.

VARCSYEN= Enables CSY from the variable decoders to come out the CSY
(VARCSY is set on HSSTRT match always, and also on HCENTER
match when in vertical sync. It is reset on HSSTOP match when VSY
and on both HBSTRT &HBSTOP matches during VSY. A reasonable
composite can be generated by setting HCENTER half a horiz line
from HSSTRT, and HBSTOP at (HSSTOP-HSSTRT) before HCENTER, with
HBSTRT at (HSSTOP-HSSTRT) before .... see below
[CODE]

Note that the meaning of the values in several other registers depend on BEAMCON0 bits, at least on AGA (the above was copied from http://blog.frosties.org/public/amiga/RandyAGA.txt)

[Toni Wilen]

from your explanation it seems like it doesn't really matter if the sync mark is found. If the DMA loads the track into memory as it did for my OS1.x loader, it trackdisk should still be able to figure it out. Could it be an issue with my MFM emulation?

Nothing gets transferred and transfer finished bit won't ever get set if sync mark is not found. ("When word sync matches: bit counter is reset and internal DMA enabled flag gets set.")

Note that wordsync check is continuous, every detected sync mark will cause resync (if not already in sync).

[bloodline]

Originally Posted by Toni Wilen

Nothing gets transferred and transfer finished bit won't ever get set if sync mark is not found. ("When word sync matches: bit counter is reset and internal DMA enabled flag gets set.")

This is true for a real Paula chip, but my emulation just waits for the dmacon, dsklen bits to signal the DMA is good to start a transfer, it then waits for dsklen, length to be non zero and starts the transfer, raising a disk block interrupt when dsklen ==0 (i.e. the track has loaded into memory).
This simple model works fine for OS1.x (I've had no problems loading disks from any of my 4 emulated drives at the same time).

To try and boot OS2, I added a condition to not start the transfer to memory until the buffer finds a sync mark, again this boots OS1.x, but OS2 shows the "Not a DOS disk" error message I attached to a previous post.

Note that wordsync check is continuous, every detected sync mark will cause resync (if not already in sync).

I'm confused, because OS2 doesn't check the word sync bit or enable the disk sync int, so in my model, once the first sync has initiated the transfer, it doesn't have any other effect on the operating system.

Ostensibly OS2 should behave the same as OS1.x in this situation, unless my model has missed something OS2 does check?

-Edit-
For those playing along at home, DF0:
OS1.3: dsklen: 0x1cbe, dskpt: 0x006b14
OS2.05: dsklen: 0x1a9e, dskpt: 0x00c0fa

[kamelito]

At the OS level OS2 brings
New Features for Version 2.0
Feature Description
TD_GETGEOMETRY Device Command
TD_EJECT Device Command
IOTF _lNDEXSYNC Device Command Flag
IOTF_WORDSYNC Device Command Flag Fast RAM Buffers Now Supported

LIMITATIONS FOR SYNC'ED READS AND WRITES There is a delay between the index pulse and the start of bits coming in from the drive (e.g. dma started). It is in the range of 135-200 microseconds. This delay breaks down as follows: 55 microseconds for software interrupt overhead (this is the time from interrupt to the write of the DSKLEN register); 66 microsecs for one horizontal line delay (remember that disk 1/0 is synchronized with Agnus' display fetches). The last variable (0-65 microseconds) is an additional scan line since DSKLEN is poked anywhere in the horizontal line. This leaves 15 microseconds unaccounted for. In short, you will almost never get bits within the first 135 microseconds of the index pulse, and may not get it until200 microseconds. At 4 microsecs/bit, this works out to be between 4 and 7 bytes of user data delay.

[bloodline]

Originally Posted by kamelito

At the OS level OS2 brings
New Features for Version 2.0
Feature Description
TD_GETGEOMETRY Device Command
TD_EJECT Device Command
IOTF _lNDEXSYNC Device Command Flag
IOTF_WORDSYNC Device Command Flag Fast RAM Buffers Now Supported

LIMITATIONS FOR SYNC'ED READS AND WRITES There is a delay between the index pulse and the start of bits coming in from the drive (e.g. dma started). It is in the range of 135-200 microseconds. This delay breaks down as follows: 55 microseconds for software interrupt overhead (this is the time from interrupt to the write of the DSKLEN register); 66 microsecs for one horizontal line delay (remember that disk 1/0 is synchronized with Agnus' display fetches). The last variable (0-65 microseconds) is an additional scan line since DSKLEN is poked anywhere in the horizontal line. This leaves 15 microseconds unaccounted for. In short, you will almost never get bits within the first 135 microseconds of the index pulse, and may not get it until200 microseconds. At 4 microsecs/bit, this works out to be between 4 and 7 bytes of user data delay.

Ok, it’s easy enough for me to introduce a delay before the start of the DMA transfer, but I feel the warnings here are just ensuring minimum times for physical disk hardware, which obviously we don’t need to worry about.

As soon as the registers contain valid values, it must be safe to perform the transfer operation!?


-edit- I'm increasing inclined to believe my Disk and DMA emulation isn't the problem... I think it's the OS2 MFM decode, now my blitter code works for OS1.x but it doesn't work for the OS2 insert disk screen, perhaps it doesn't work for the decode either... I must have made an OS1.x compatible assumption somewhere...

[Toni Wilen]

trackdisk.device new KS2.0+ options don't really have anything to do with how low level disk handling works.

You sure you handle disk track "wrap around" properly including resync? (If it causes wordsync unaligment). Blitter can't be the cause because KS 2.0+ trackdisk.device does not use blitter, at all.

Dump the memory where trackdisk.device loaded the track data after disk DMA has finished and manually check that it makes sense? Make sure each sector is complete and wordsync markers are in expected positions etc.

[bloodline]

Originally Posted by Toni Wilen

trackdisk.device new KS2.0+ options don't really have anything to do with how low level disk handling works.

You sure you handle disk track "wrap around" properly including resync? (If it causes wordsync unaligment). Blitter can't be the cause because KS 2.0+ trackdisk.device does not use blitter, at all.

Dump the memory where trackdisk.device loaded the track data after disk DMA has finished and manually check that it makes sense? Make sure each sector is complete and wordsync markers are in expected positions etc.

Excellent suggestions! I will watch the memory and see what it looks like.

My first guess was the wrap around being wrong (as this is what stopped me last year), and seeing a “Not a DOS Disk” error suggests that the data is there, but malformed. But this code still works with KS1.x... That confuses me.

Now what exactly should happen when a sync mark is found? My code currently just uses it to start the DMA, after that it just raises the interrupt and sets the word sync bit (but these aren’t used by trackdisk), there isn’t much else I can see it would do! My code can’t be unaligned as it always reads the track in words.

[hooverphonique]

Originally Posted by bloodline

Excellent suggestions! I will watch the memory and see what it looks like.

My first guess was the wrap around being wrong (as this is what stopped me last year), and seeing a “Not a DOS Disk” error suggests that the data is there, but malformed. But this code still works with KS1.x... That confuses me.

Now what exactly should happen when a sync mark is found? My code currently just uses it to start the DMA, after that it just raises the interrupt and sets the word sync bit (but these aren’t used by trackdisk), there isn’t much else I can see it would do! My code can’t be unaligned as it always reads the track in words.

I suppose ks1, when reaching the track gap, will have to do a resync.. this also happens using sync hardware, according to Toni above, so after the gap, the hw will sync the data again.. The raw data you use probably isn't sync'ed any longer after crossing the gap. If so, you need to emulate the continous hw sync for the data after the gap to be in sync (or you could pre-organise your raw data to have a gap size divisible by 16 bits).

[bloodline]

Originally Posted by hooverphonique

I suppose ks1, when reaching the track gap, will have to do a resync.. this also happens using sync hardware, according to Toni above, so after the gap, the hw will sync the data again.. The raw data you use probably isn't sync'ed any longer after crossing the gap. If so, you need to emulate the continous hw sync for the data after the gap to be in sync (or you could pre-organise your raw data to have a gap size divisible by 16 bits).

Yes, I'm generating the MFM data at runtime from the ADF data , my track gap is always 700 bytes starting with 0xAAA85555. So a complete track is always 12668 bytes. It is always word aligned. It shouldn't need a resync.

-Edit- The loaded data in memory looks exactly as it should starting with the second sync mark of the first sector.
Also, I've tried to feed the data without the track gap, doesn't make any difference

-edit2- I'm going around in circles with this floppy disk issue... Until someone has any ideas, I'm looking at the gayle IDE registers... so far my emulator is doing this at startup... now to find some info on what these registers are:

Write to IDE Register 0xde109a (0x00bfff)
Write Byte to IDE Register 0xde1000 (0x000000)
Read Byte From IDE Register 0xde1000
Read Byte From IDE Register 0xde1000
Read Byte From IDE Register 0xde1000
Read Byte From IDE Register 0xde1000
Read From IDE Register 0xdc001c
Read Byte From IDE Register 0xdc003f
Write Byte to IDE Register 0xdc003f (0x000000)
Write Byte to IDE Register 0xdc003b (0x000000)
Write Byte to IDE Register 0xdc0037 (0x000009)
Write Byte to IDE Register 0xdc0033 (0x000005)
Read Byte From IDE Register 0xdc0033
Read Byte From IDE Register 0xdc0037
Write to IDE Register 0xde109a (0x00bfff)
Write Byte to IDE Register 0xde1000 (0x000000)
Read Byte From IDE Register 0xde1000
Read Byte From IDE Register 0xde1000
Read Byte From IDE Register 0xde1000
Read Byte From IDE Register 0xde1000

[kamelito]

@bloodline
Found this about Gayle.
https://computerarchive.org/files/co...Manual-ENG.pdf