Prince Of Persia Code Review (2013)
fabiensanglard.net
fabiensanglard.net
One of the custom chip on the Amiga had hardware for teh track decoding. So the Amiga could read the disk while performing other operations, the data would come in via DMA (direct memopry access) of the co-processor.
(MacOS used variable-speed, that is how it fitted more sectors on outer tracks and achieved 800K.)
One of the HD manufacturers of the time, either Conner or Maxtor, was known to use Amiga 3000 machines to test their SCSI disks, because of the CPU/chipset/OS/FS combination. Not many systems were able to extract 90%+ of theoretical throughput like the A3000 could.
Can it be that the Amiga 500 had in its case a place for a HDD? (I don't remember using external cases, but maybe I have forgotten...)
There was no room in the A500 for a 3.5" drive. Later, the A1200 and A600 had a built-in IDE controller and an internal bay, but for a 2.5" disk.
http://amiga.resource.cx/photos/photos/a590-5.jpg
I only ever saw them with SCSI drives in person, but they also sold XT units. Maybe you saw the latter?
http://amigadev.elowar.com/read/ADCD_2.1/Devices_Manual_guid...
It read full tracks at a time, but you can see from the doc there were 11/22 sectors with no inter sector gaps, but there are separate sectors of 512 bytes which are addressed in the file system structures.
If you decode $4489 via MFM then re-encode that byte, you'll get a 1-bit difference. This is why it works as a sync marker: even if you wrote that byte in the data area of the sector, it wouldn't encode the same way because of the missing clock :)
It's a common trick on radio systems too -- a short burst of data which can't be obtained through normal encoding processes (invalid FEC bits, flipped parity, etc).
If memory serves correct, the raw data was pulled in from disk to memory DMA-style, but the actual decoding could be done either using the blitter or 68k.
True about performing operations whilst loading from disk though; I coded a trackloader demo that was loading the next part of the demo whilst the current part was ongoing, using the 68k to decode so that the blitter could be hammered for graphic effects!
sadly no, it was just deserializing head magnetic flux data (encoded as pulses) to raw bytestream, you still had to compute actual data out of it. Whats worse Commodore shipped same, outdated even in 1987, Double Density chip for the whole life of Amiga.
The fun trick is, with a drive controller which works based on "time between pulses" (DiscFerret, Catweasel, etc) you can do all of the above with a CAV disk drive just by tweaking the read/write clock. Same trick probably works for discrete drive controllers like the 765 and 1771 (I say probably because I haven't checked the datasheet!).
ORG directives were really just hints.
There was no operating system and no
linker/loader on Apple II: The developer
had to "somehow" manage to transfer the
instructions from floppy disc to the
intended location.
As he points out, when building complex programs on the Apple II, you had to keep track of where to load modules yourself, precisely because there was no metadata in the object file. Nothing prevented you from loading a module compiled at one ORG at a different address... well, nothing except the fact that it would probably crash.
There are some factors that can simplify relocation: only allow relocation to page boundaries (i.e. $xx00 addresses) and possibly keeping the routines shorter than a page.
For example, here's a single page, page boundary constrained relocator for a routine with two patch points:
; x = page
relocate_routine
stx rel_sta+2
; patch
stx patch1+2
stx patch2+2
ldy #0
copy
lda routine_template,y
rel_sta:
sta $0000,y
iny
bne copy
rts
; some routine assembled for any origin $xx00
routine_template
bne continue
patch1
jmp done
continue
...
patch2
jsr print
...
done
rts
print
...
rtsI don't think ability to address 64k means the CPU is 16 bit. The 6502 is a very 8 bit processor AFAIK. The main registers are 8 bit, most operations work on 8 bit registers.
I think when the Atari Jaguar was released they used the same kind of logic to market it as a 64-bit system since technically some part of it was using 64-bit processing, but the CPUs were still 32-bit.
It's just nitpicking though, I thoroughly enjoy Fabien's writing and I can highly recommend the couple of books he's written about reverse engineering Id Software games. On HN people seem to confuse "hacking" with "growth hacking" a lot of times, and Fabien's writing is thankfully on the right side of that fence.
referring to the 16-bit 68000 processor and ... 32-bit something else, I forget :)
[1] but only 24 address lines, which led to "interesting" bugs when people had written code that used the top byte of addresses for other purposes and their code was then run on a 68020 or higher.
By that definition the 68000 and 8086 are 16-bit processor (which makes sense), however the stripped down variants 68008 and 8088 would be considered 8-bit processors... and this is where this simple model breaks down ;)
The Z80 is 8-bit as most of its internal operations work over this data size and its registered are 8-bit. It can perform some 16-bit operations over two registers, but this is less natural to the design (based upon the 8-bit 8080).
The 8088 is 16-bit as its registers are naturally 16-bit even though there are also ways to address them as 8-bit halved. While the distinction between registers that are 8-bit but can be paired (Z80) or 16-bit but can be halved (8086/8088) may seem arbitrary on its own but looking into the instructions available and how they perform makes which side a chip sits on more obvious.
How much can be read at once is not the right differentiator, as it is essentially an interface issue. The internals of the 8088 are the same as those of an 8086, apart from those at the interface which break the 16-bit requests into 8-bit ones, they just have to wait longer for the signal that data has arrived/left.
Another common one that can confuse is the 80386SX: these are 32 bit chips (essentially the same design as the original 80386, latterly referred to as 80386DX) with a 16-bit data bus (so 32-bit requests are split as seen with 16-bit ones with the 8088) and a 24-bit address bus (limiting them to 16Mb physical memory like 80286 chips). These limited bus sizes allowed them to be used on motherboard designs originally intended for older 80286 units.
Other confusions come from specialist instructions: floating point operations using larger (40- & 80-bit) special purpose registers, SIMD instructions (such as those in the MMX set, introduced on 32-bit Pentium lines, operated over 64-bit collections of smaller values), etc.
Sometimes it works the other way around: the original Pentium lines (up to the Pentium 4) were 32-bit chips even though they had a 64-bit data bus (this made loading data into the L1 cache faster, rather than marking the chip out as 64-bit overall) and some 64-bit instructions.
It'd have been more interesting to link it once more complete.