Where to find information ?

I'm trying to find a couple of pieces of info that don't appear to be written down anywhere obvious(not in the manuals, and not in a way I can just extract it from Sim Coupe)

1. How are the serial ports mapped onto EC. The device used has both data and control/status registers so I assume some of the high bits select. From the schematic I am guessing A0-A2 are taken from bits 8-10 of the I/O port ?

2. What does BOOT expect for a bootable disk, what does it load, where does it load from and what state is the machine in (memory map wise in particular) when  it transfers control ?

Trying to port an OS to Sam (or Sim anyway) Coupe.


Hi Alan,

Not the most technical of people here - from memory I believe in the case of the BOOT command, the SAM disk drive loads in the first 512 byte  sector from track 4, first sector. The following track/sector is taken from the last 2 bytes loaded.

SamDos/Bdos/Masterdos would all work fairly similar in that sense.

(SAMDOS is the original DOS, MasterDos a later enhanced one (which supported external RAM expansion) - BDOS supports all the Hard Drive standards, plus the Trinity SD Interface.)

Also see the entry on ProDos

In reply to by David

Yes it loads it into the top most unused 16k page as describe in the technical manual here..

When SAMDOS is loaded the ROM looks at its available memory and loads
SAMDOS into the last free 16K page. The ROM uses the last two 16K pages
for SCREEN 1, so SAMDOS usually loads into the third from last 16K page,
but the page will be different if extra screens have been opened before
SAMDOS is loaded. Address 5BC2H (SVAR 450) holds the page number used by
SAMDOS, or zero if SAMDOS has not been loaded.
PEEK SVAR 450*16384+16384 will give the start address of SAMDOS, When a
DOS command is issued the DOS is loaded into section B (4000H) of the
64k addressing space, the command is performed, and the DOS is then
paged out.



Not sure what you mean by serial and EC - Sam didnt have serial as standard.  Are you talking about an interface?


With the serial stuff, if you mean the euroconnector then its not serial as such.  You can write to it and read from it using IN and OUT and check things like the /IOREQ line etc.  Address lines are based set depending on the A/BC register and the command used

The Comms interface which plugs /onto/ the euro/edge connector does provide a serial port. I never had one of these interfaces. 

For networking /actual/ SAMs together I /think/ the midi ports could be used since all SAMs have a midi port.

Thanks - I missed the implications of that and was somewhat confused by the fact that the bootable thing was a file, but if it's the first file there then that all makes sense.

The serial question was regards the Comms Interface.




If you want the nitty gritty on booting - see the ROM disassembly - if you search for PERFORM BOOT ACTION then you're in the relevant part.

The first sector of track 4 is loaded at 0x8000, the four bytes at offset 256 are checked for the magic BOOT (see BTWD - in which some bits are ignored). Control is then passed to whatever is in the boot sector (JP 0x8009) - this is responsible for loading whatever it else it wants / needs.

If a file is saved to an empty disk, it's contents starts at track 4 sector 1 - the first 4 tracks (0-3) are for the FAT.

Yes.. I've been avoiding the Sam because the memory management is unusual and quite tricky. The lack of a text mode or 1bpp video also means a certain amount of new development work is needed. Don't expect anything soon!

But the time has come to have a crack at it, after all it was once a local machine here in Swansea.



I'm guessing that with tricky memory management you are referring to two 16k pages being rolled in at once?

If you require the external megabyte expansion - it's pages can be paged in into high memory separately - but reading your readme - I think you are already aware of this.

1bpp video is available if you choose video mode 1 (identical to spectrum mode) or 2 (timex-ish mode) - the new dev work for mode 3 / 4 could then be postponed until a more fitting time.

Actually the hairy bit is the fact you've got 2 x 32K mappings not 4 x 16K or a fixed high area. It makes life much more interesting when you need to switch the whole 64K and even more so if you want to efficiently copy 32K banks around because you can't just map both halves and ldir as you also need to find somewhere to put the code to run.

It's just a bit different to most systems and requires some care with stacks and interrupts.


So you do mean (32k mapping) the same as I mean (two 16k pages being rolled in at once). There is a slight nuance however, is that they are 16k pages. So if you consider the banks:

A - LMPR - 0000 - 3fff
B - LMPR - 4000 - 7fff
C - HMPR - 8000 - bfff
D - HMPR - c000 - ffff

When you put page 0 into C, page 1 automatically rolls into D. But you can also put page 1 into C, which rolls page 2 into D - so it can be a rolling area.

When using external megabyte memory - C and D can be paged in separately.

Alternatively you could burn a replacement ROM which can then mask over page A leaving B + CD and or over page D - from the tech manual:

LMPR - Low Memory Page Register (250 dec) This read/write register is used mainly for the control of paging low memory in the CPU's addressing range.

  • Bit 0 R/W BCD 1 of low memory page control.
  • Bit 1 R/W BCD 2 of low memory page control.
  • Bit 2 R/W BCD 4 of low memory page control.
  • Bit 3 R/W BCD 8 of low memory page control.
  • Bit 4 R/W BCD 16 of low memory bank control.
  • Bit 5 R/W RAM0 when bit set high, RAM replaces the first half of the ROM (ie ROM0) in section A of the CPU address map.
  • Bit 6 R/W ROM1 when bit set high, the second half of the ROM (ie ROM1) replaces the RAM in section D of the CPU address map
  • Bit 7 R/W WPRAM Write Protection of the RAM in section A of the CPU address map is enabled when this bit is set high.

But yeah - hairy is starting to make sense :-) From a demo coder / single program point of view this was all less of a problem.

I noticed he had a fork but didn't make the connection as to who he was

The port is slowly getting there. I have the worse of the 32K/32K handling done although none of it is yet optimized. Keyboard, console and interrupts work. Loading the first user application from disk works, but something goes a bit weird during the early user space when it tries to open files.



Looking forward to seeing it develop!

Chris Pile also did some excellent work with his ProDos - his CP/M Compatible system.. including support for the major storage options.

Been distracted with other stuff (like building my RC2014 machine) but had a bit more time to dig down and kill off the nasty remaining bugs. Fuzix on SAM now kind of works. It's a bit slower than it should be and it only supports the AtomLite controller and Sambus RTC so far.

Good enough to run the system, sit in a shell and play startrek, zork and sokoban 8)

Next stops probably the floppy controller and mouse, although the mouse interface appears to have a most peculiar software interface.