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…
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
Yes it loads it into the top…
In reply to Hi Alan, Not the most… by David
Yes it loads it into the top most unused 16k page as describe in the technical manual here..
Not sure what you mean by serial and EC - Sam didnt have serial as standard. Are you talking about an interface?
EC = EuroConnector
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
Comms interface perhaps?
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…
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.
FuzixOS I presume?
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…
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.
But yeah - hairy is starting to make sense :-) From a demo coder / single program point of view this was all less of a problem.
Looks like Simon Owen …
Looks like Simon Owen started to look at this a while back: https://github.com/simonowen/FUZIX - possibly with a view to porting it to the SAM after all his work on the other SAM emulators/PacMan stuff he's done.
Might be worth dropping him a note firstname.lastname@example.org as he's well versed in porting other OS's to the Coupé.
Thanks for the pointer
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…
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.
Fuzix on SAM
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.
Cool! If you get the floppy…
In reply to Fuzix on SAM by EtchedPixels
Cool! If you get the floppy working I'll give it a go on real hardware :-)