16 February 2018, 11:30 | #61 | |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,624
|
Quote:
|
|
16 February 2018, 12:35 | #62 | |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Quote:
Last edited by bloodline; 16 February 2018 at 12:52. |
|
16 February 2018, 12:41 | #63 | |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Quote:
I think I have achieved this for KS1.2, it only needs the CIAs (for the timers) an the interrupt hardware. But I want to boot KS3.0 so I can emulate the IDE for booting and direct that to the real mass storage hardware. KS3 is more tricky so I am implementing more of the hardware emulation to see what is going wrong, and it's really good fun! |
|
16 February 2018, 12:58 | #64 | |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Quote:
The OS then turns the disk motor off... all good! After a few seconds the emulator Gurus I must be missing something -edit- My address calculation was off, I now read in 7358 MFM words (as requested in dsklen) starting the address specified by dskpt... when I generate a dskblk int at this point the OS starts to randomly read memory... So I must be nuking something important in ram :-| -edit 2- I found another bug, I was halving the address in dskpt (because my earlier implementation addressed the memory as words), now that is fixed, the MFM track loads fine and the blitter is fired up! let's see where this rabbit hole leads :-D Last edited by bloodline; 16 February 2018 at 13:48. |
|
16 February 2018, 15:04 | #65 |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Observing this more... it seems the track is loaded into ram, the blitter operates upon it, the result is garbage* (I am observing the memory pointed by channel D)... the OS tries again, and again, and again... same result... it steps the head to track 1 and then back to 0,and tries a further 4 times... since the result is meaningless each time it just fails... eventually the OS just gives up, switches the drive motor off and stops working.
Not ideal, but definitely progress -Edit- Conveniently to OS makes Long write to bltbmod register when it is using the blitter for floppy disk work, which makes trapping that call rather easy. *Actually not garbage, but what appears to be encoded MFM data... I assumed the blitter was supposed to be helping decode the data... Last edited by bloodline; 18 February 2018 at 17:44. |
18 February 2018, 20:51 | #66 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,624
|
|
19 February 2018, 14:14 | #67 |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
This baremetal-emu is a very interesting idea!
Hope you can finish this project one day. The thread here is also very interesting to read and gives some insight to how things were done on our beloved Amiga. The MFM-encoding thing rises a question in my head: What if C= (or some third party) would have added some small controller to the floppy-ports of the CIA (let's say a 65CE02) to do the MFM decoding already there? This would reduce the transmitted data by roughly 50% - or double the max. speed. Wouldn't that have been a nice way to hook HD-floppy-drives to the Amiga without modifying Paula? |
19 February 2018, 16:47 | #68 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
Quote:
|
||
19 February 2018, 16:48 | #69 | ||
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Quote:
Quote:
Hooking the floppy drive data output up to Paula and doing the MFM decoding in software is a classic case of money saving, I think if you were to add any more hardware to the Amiga to handle floppy disks, you would just add a proper floppy controller chip. it would be much cheaper and simpler than trying to stick another chip in the middle of the current process. |
||
19 February 2018, 17:09 | #70 | |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
Quote:
a new controller would probably break compatibility for all the strange formats games used to work with - and since Nicholson left very early and documentation was non-existent, Paula stayed a mystery till the end... that's where my idea comes in: for dd-floppies you would use Paula as always ignoring your additional controller - for hd-floppies a 6502-like thingy (that C= already had) does the decoding and saves bandwidth.... Back to your Emulator: you could do maybe the same in emulation and deliver already decoded-content into chipram (even for dd), so no need for emu-blitter or emu-cpu to do the heavy work. (of course you would have to disable the decoding function in kickstart in this case) |
|
19 February 2018, 18:13 | #71 | |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Quote:
It would certainly make my life easier if I didn't need to encode everything before I sent it to the disk DMA... but then it would be much easier if I didn't have to support the Cylinder, surface, sector geometry as well and just have a block interface, which is why I plan to support the Gayle IDE interface, which is just that, a proper "modern" disk interface. At which point you can dump the floppy and just use KS3.0 |
|
19 February 2018, 18:37 | #72 | ||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,294
|
Quote:
http://aminet.net/package/disk/misc/TrackSalve with some modifications... Quote:
that sounds reasonable! |
||
21 February 2018, 13:22 | #73 |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Ok, I tried running rawread again on the same (Workbench 1.3) disk and predictably (if I've understood Toni correctly) have a different disk image, but this one is totally unreadable by my Emulator.
To understand exactly what is going wrong with my code I think we need to work through a bit of theory and see where my mental model deviates from reality. First the low level disk structure: The disk is divided up into 80 cylinders, i.e. Concentric rings starting at the outer edge of the disk moving in towards the centre of the disk. Each cylinder has a lower and an upper surface. Each cylinder surface (henceforth known as a track) is then divided into 11 sectors (there is also apparently a "gap area" here dividing the first and last sector, but I'm not concerned about that right now). A sector is 544 data bytes (actual low level format data, not mfm code, not Amiga file system data) in size. If we do the maths 80*2*11*544 (cylinders*surfaces*sectors*bytes), that comes to 957,440 data bytes. The first 32bytes of data in each sector is low level format data (aka the header), the remaining 512bytes is the actual data available to the filesystem. Another quick calculation (80*2*11*512) gives us the Amiga's formatted capacity of 901,120 bytes! The low level format sector header: //Sector Sync uint8_t 0x0; uint8_t 0x0; uint8_t 0xA1; // not really 0xA1 as this will have a missing clock bit in MFM code uint8_t 0xA1; // as above //Sector Info uint8_t 0xFF; // Amiga disk identification uint8_t 0xXX; // Track number = (cylinderNumber * 2) + surface number <0 or 1> uint8_t 0xXX; // sector number (0 to 10) uint8_t 0xXX; // countdown to track end (11 to 1) //Sector label, apparently unused and always 0 uint32_t label0 0x0; uint32_t label1 0x0; uint32_t label2 0x0; uint32_t label3 0x0; //Header checksum... using the XOR algorithm from Track Salve uint32_t hChecksum 0xXXXXXXXX; //Data checksum... as above uint32_t dChecksum 0xXXXXXXXX; //Data block uint8_t block[512]; This all seems quite straightforward, and I have already written a function which takes an ADF and spits out a file with this structure. Now comes the bit that seems to be causing problems. MFM: This is a simple encoding scheme, each single data bit of a data stream as two mfm bits. The least significant bit is the same as the data bit, the most significant bit is position dependant... 1 -> 01 0 -> 00 (if the preceding data but was a 1) 0 -> 10 (if the preceding data bit was also 0) Following the above scheme it is really simple to encode a data stream into mfm code. But the Amiga being the Amiga, it's not that simple. The odd and even bits are arranged separately, which is actually a pretty clever way to allow quick decoding simply by masking, shifting the odd bits and then ORing them together (all operations the blitter can do). An ordinary byte: STSTSTST encoded in this scheme looks like this (where S are the odd bits and T are the even bits: To encode the odd section first shift right by one place: 0STSTSTS Then "AND" with 0x55 to remove the original even bits, resulting in 0S0S0S0S The even section is simply the original byte AND with 0x55. So the byte encoded on disks a word which looks like this: 0S0S0S0S0T0T0T0T The Amiga's scheme is a bit more complex, as the odd bits are all encoded as a single block followed by the even bits. I then run a loop over the encoded data to add the correct mfm clocking bits where appropriate. Now, when the track disk device requests a track of data from the floppy it is provided with 11 sectors of this data (5984 words) followed by 320+ words of 0xAA to simulate the gap between the first sector and the last. But it seems, the trackdisk.device is not fooled by this... |
21 February 2018, 13:53 | #74 |
Registered User
Join Date: Aug 2004
Location:
Posts: 3,335
|
Do you "wrap around" the MFM data? Trackdisk will start reading (probably) when the head is in the middle of a sector's data. It reads more than one revolution in order to ensure all sectors are unbroken/complete in the track buffer.
|
21 February 2018, 14:03 | #75 |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Yes, if the word counter goes above 6319, it just wraps back around the the start of the track.
|
21 February 2018, 14:09 | #76 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
trackdisk.device won't care if all reads start from "beginning" of track. Real floppy position does not need to be emulated. Only some custom track loaders need it.
|
21 February 2018, 14:20 | #77 |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Exactly, so I must producing garbage data... is there any way I could feed my data into UAE... Perhaps package it in the adf format produced by rawread?
|
21 February 2018, 14:34 | #78 |
Registered User
Join Date: Dec 2016
Location: Finland
Posts: 168
|
I don't think that the Amiga floppy hardware is poorly designed. It is more flexible than the PC floppy controller, Amiga can read 720 kb DOS disks, but the PC disk drive can't read Amiga formatted disks. Also, some games like SWIV and Ninja Warriors are able to read from disk during gameplay (without slowing down action) on an A500, so the disk system isn't too slow or poorly integrated with interrupts either. I haven't seen any other computer being able to do that.
|
21 February 2018, 14:55 | #79 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
Quote:
Quote:
Hardwired format requirement is practically the only real limit, in all other situations it is better than Amiga floppy "controller". It is only flexible because it is so simple, not much more than a PLL + bi-directional 16-bit parallel/serial converter + few CIA software controllable IO lines. |
||
21 February 2018, 14:57 | #80 |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Amiga emulator for iOS | steviebwoy | support.OtherUAE | 35 | 15 November 2014 10:14 |
Amiga emulator for a PSP? | Vars191 | support.OtherUAE | 1 | 09 May 2010 02:08 |
Frederic's Emulator inside and Emulator thread | Fred the Fop | Retrogaming General Discussion | 22 | 09 March 2006 07:31 |
ADF Files -> Amiga(amiga with dos Emulator) | Schattenmeister | support.Hardware | 8 | 14 October 2003 00:10 |
Which Amiga emulator is best? | Tim Janssen | Amiga scene | 45 | 15 February 2002 19:52 |
|
|