
Prince Of Persia Code Review (2013) - Reedx
http://fabiensanglard.net/prince_of_persia/index.php
======
pierrebai
About the disk format: the Amiga native disk format was just one huge sector
per track. That is how the Amiga fitted 880K on the same disk MS-DOS filled
with 720K and MacOS 800K.

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.)

~~~
zepearl
I owned an Amiga 500 and at a certain point I bought for it a HDD (20 MBs, if
I remember correctly) => then later I switched to an IBM-compatible (386sx
with a HDD) and, subjectively, I thought that the HDD of the IBM-compatible
was slower than the one I previously used on the Amiga => any HW reason why
the Amiga-HDD might be faster than the IBM-HDD, or did I just imagine it?

~~~
puzzle
It might have been a SCSI drive/controller, but it might have also been that
you used FastFileSystem, which was pretty efficient.

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.

~~~
zepearl
Thx - it was just some sort of standard HDD for Amiga 500 - cannot remember
anything specific about it... .

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...)

~~~
puzzle
The A590 was a drive that plugged on the left side of the A500. It usually
came with a 20MB SCSI disk inside...

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.

~~~
jacobush
The 590 had a SCSI controller with _DMA_ , but only for the external SCSI
connector. The internal drive was 8-but IDE and dog slow. So if it was faster,
it must be chalked up to better OS, better filesystem and I would assume a
68000 at 7Mhz was faster than a 4.77Mhz 8088 at shuffling data around.
Especially since the memory data bus was 16 bit wide for the Amiga but only 8
bit wide for the PC. (Right?!)

~~~
puzzle
The A590 had both a SCSI and an XT header for internal drives (on the right
side):

[http://amiga.resource.cx/photos/photos/a590-5.jpg](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?

~~~
jacobush
If they sold'em with XT-IDE inside, I was probably unfortunate to have on of
those. Still beat swapping floppies. Thanks to the HDD I could compile C
programs without switching floppies all the time. IIRC I had the compiler and
the headers on one floppy and the linker etc on another. Eventually I made
DICE (Matt Dillon yo!) fit on one floppy. Or was it an early Lattice C?? Can't
remember.:-P By that time I had bought a 486SX for uni, so I reluctantly used
Turbo C instead. Turbo C was just too good to pass up...

------
CamperBob2

       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. 
    

Well, no. .ORG directives had nothing to do with any of that. They were (and
are) used to tell the assembler how to fix up absolute references such as
JMPs, JSRs, and loads/stores to variables defined in the code.

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.

~~~
joezydeco
You could write 6502 code to be completely relocatable, but at a cost of space
and a more complex assembler.

~~~
tinus_hn
The 6502 can only do small +128/-127 bytes relative jumps so that would be
pretty complex indeed.

~~~
boomlinde
Typically you'd patch the relocatable routine before inserting it at the
desired memory location, simply overwriting the location-dependent
instructions like jsr and absolute jmp with new operands. This isn't very
complex, especially if the relocator doesn't need to be position independent
itself.

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
            ...
            rts

~~~
tinus_hn
If the relocator is not position independent then the solution is not
completely relocateble. I don’t even know how you would get access to the
program counter without trashing some memory.

------
antirez
> the 6502 is a simple 16 bits processor

I 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.

~~~
flohofwoe
I think it's best to go with the "external data bus size", which is 8-bit on
the processors typically known as "8-bit processors" (6502, Z80, i8080, 6809
etc...). Those processors can read one 8-bit byte in one memory access. For
instance, even though the Z80 has 16-bit registers, can load 16-bit values
from memory (and even has some 16-bit arithmetic operations), a 16-bit memory
access takes 2 separate memory accesses through the 8-bit data bus.

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 ;)

~~~
dspillett
"bitness" is defined by the natural data size of common operations.

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.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=5917888](https://news.ycombinator.com/item?id=5917888)

------
snvzz
While nice, it doesn't go very far, yet.

It'd have been more interesting to link it once more complete.

~~~
fabiensanglard
I lost interest. I don't think i will ever finish it :P!

~~~
snvzz
Damn. What a tease.

------
StacyC
I had so much fun playing this in college on a Mac Plus in our little computer
room (closet)!

------
bredren
(2013)

~~~
fabiensanglard
Boy, this makes me feel old.

~~~
Moru
You were also expecting 1989 as the year? :)

