Where to find information ?

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

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.

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.

https://github.com/EtchedPixels/FUZIX

Cool :-)

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.

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.

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 simon@simonowen.com as he's well versed in porting other OS's to the Coupé.

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.

Cool! If you get the floppy working I'll give it a go on real hardware :-)