PRIMAL is coming

[zhulien]

A very long time ago I started coding an OS for the CPC, it was a preemptive multitasking OS which had a kernel and quite a few proof of concepts with a design for some elementary windowing.  Then came along Symbos, no way can I compete with that!!! well, anyway, I thought about it and even got some positive thoughts my way from Prodatron.  I had a long hard think about it and in the end, I scrapped the direction I was going - which likely would have been something like Symbos, but perhaps not as good.  After seeing the current-day Symbos, I can almost say without doubt my OS wouldn't be as good

So... back to the drawing board, what can I do to repurpose some of what I have done but give some value without taking away the userbase of Symbos and/or AMSDOS and/or CP/M and/or FutureOS? and others...

So here comes PRIMAL.  Is it an OS?  Is it an API layer?  Well it is both and the API Level 1 version is almost here.

What it allows someone to do is write software to run on many platforms.  API Level 1 can take over a whole machine (like an OS) and in fact I plan to write a shell for it.  However, it can also run inside an OS.  More details to come, but the API which is jumpblock based, is multi-leveled.  Level 1 allows for console type applications.  Level 2 will introduce better memory management and interrupts and likely screen positioning/terminal emulation (but... I might move this last point into LEVEL 1). 

Levels are structured as follows: Loader (aka Level 1), BIOS (aka Level 2), Kernel (aka Level 3), Shell (aka optional Level 4).  An application can use any or all 4 of the Levels, in reality it is intended the Shell doesn't offer APIs, but it could offer Shell-like facilities.  The Kernel is 100% platform independent.  The BIOS will add driver support.

Targets I am currently developing:

- AMSDOS

- CPM
- Enterprise 128 (I need more tech docs to finish this one)
 - FUTUREOS (looking into it now)
 - MSXDOS
 - MSX BASIC
 - Spectrum 16k
- Spectrum+
- Spectrum +2
- Spectrum +3
 - SYMBOS

- RomWBW

- Coleco Adam

Systems I parked due to finding documentation difficult:

(I really really did look and cannot find any tech docs anywhere, but I have included them in the build chain already at least)

- Sega SC3000
- Tatung Einstein
- Exidy Sorcerer
- Tandy TRS80 (TRSDOS)

To complete Level 1 API for a platform, all that is required is to implement the following:

(All platforms above are in various states of completeness - Amstrad CPC is the most complete with only 1 function required for me to debug the non-Platform Specific stuff)

- MemTable - configuration only
- PS_RAMInit - sometimes this doesn't need to do anything, sometimes it relates to MemTable
- PS_CanSave - just returns a flag
- PS_CharIn - non-waiting character input
- PS_CharOut - character output
- PS_CharWait - waiting character input
- PS_CommandLine - give me the commandline buffer (if there is one)
- PS_Load - load a file
- PS_Save - save a file
- PS_StrIn - string input (will do this in future)
- PS_StrOutHL - string output (this can use  PS_CharOut, but... some platforms offer a faster native one)
- PS_SystemRestore - restore the host system for elegant exit (will do this in future)
- PS_SystemSave - save the host system for elegant exit (will do this in future)
- PS_Terminate - terminate elegantly if possible (symbos allows this, as an example)

Other platforms I looked at but decided against for the time being are:

- Jupiter Ace
- Sord M5
- Zx81

To qualify a platform for this, I looked at the following.  Does it have a Non-Tape Storage available?  Does it have at least 128K RAM?  Does it have the ability to go online?

More systems than I had thought satisfy all 3 of those, but in the end I have now catered for even a 16k Spectrum just to see how it goes, that is with no internet access to.  But I will be implementing virtual memory in API Level 2 (it might make Level 1 though).  With about 7K only for programming space in the 16K Spectrum, we can get about 5K main memory which also includes the Loader (522 bytes so far for Level 1, I estimate about 600 when done) and potentially 1024K of virtual memory.  Does the DivIDE work on a Spectrum 16k?

To Git or not to Git?

I have a love hate relationship with Git.  But I have a Love Love relationship with SVN.  SVN allows me to develop my stuff from anywhere in the World without having the replicate a massive strucutre of shared code every time I want to make little changes to stuff.  Unfortunately Git doesn't allow that. And a few Pros and Cons either way depending on how you like to work.

I have only used Git and Github in a corporate environment, before I put PRIMAL into Git and make it publicly available, any advice from anyone that I should be aware of first?

Also, does anyone have any cool commandline programs (don't swamp me), but if you have a pretty decent one, for me to port to PRIMAL so there is something useful from the start?  An assembler perhaps?  A commandline monitor?

[Gryzor]

So I basically understood 5% of all that, but it sounds... exciting? 😁

No really, the cross platform thing sounds very nice, I'd really like to see how people could use it in that direction.

[zhulien]

So I babysit understood 5% of all that, but it sounds... exciting? 😁

No really, the cross platform thing sounds very nice, I'd really like to see how people could use it in that direction.

Basically if someone codes a console tool with this, it will work on all those platforms with no changes - only the loader which is a very minimal API needs to be coded for a new platform, and all existing well behaved code should just work. Hopefully we can give something to those older and less-good Z80 computers and in turn they may code stuff that we can use.  When I get to Level 2, it goes into non-console only territory.

[zhulien]

I now coded pretty much all the CPC stuff that is needed to debug it. 

API Level 1:

Coded: Error, MemTable, RAMSize, Terminate, Load, Decompress (has anyone got some nice decompression code that isn't too big?), CheckPrimal, Relocate, Patch, LDRPCFile (Load, Decompress, Relocate, Patch, Call Init File), CanSave, Save, CharOut, StrOutHL, StrOutPC, CharIn, CharWait, StrCompare, StrLen, StrSkip

Not Yet Coded (And Not required for Debugging working software): CommandLine, FileSize (how do I get a CPC file size?), Build, SystemRestore, SystemSave, StrIn

1369 bytes so far for CPC version: of Loader (811 bytes), BIOS (183 bytes).  Then the following are platform independent: Kernel (180 bytes), Shell (195 bytes) <--- not a full shell yet, just a dummy to prove the relocation & patching.
1275 bytes so far for Spectrum 16K: Loader (763 bytes), BIOS (187 byets).  A few functions however left to code for it (PS_Load, PS_Save, PS_CanSave).  Let's say the Virtual Memory functions will take just under 1kb... is it too much to take away from a 7.5Kb Free RAM of a Spectrum 16K to give it another 1024Kb Virtual RAM?  (have to wonder why someone would use a mass storage device on a 16K computer though...).  ZX81 is worst because the RAM wobble and likely no mass storage (but it could run software in a 64kb expansion).

And I will support several memory models on CPC once debugged.

[Animalgril987]

@zhulien Does this help for the Tandy?
http://www.1000bit.it/support/manuali/trs/TRS-80%20Technical%20Manual%20(1978)(Radio%20Shack)(pdf).pdf

[Animalgril987]

And the Sega?
https://segaretro.org/SC-3000_official_documentation

[Animalgril987]

This is the best I could find for the Einstein:
http://www.tatungeinstein.co.uk/front/mans.htm

[Animalgril987]

And Exidy Sorcerer:
http://www.bitsavers.org/pdf/exidy/Exidy_Sorcerer_2_Technical_Manual_Dec1979.pdf

[zhulien]

I have created memory layers for the following CPC configurations - any can be chosen if you have enough RAM:  0 extra (464/664), 64k extra (6128/6128+), 256k, 256k Silicon Disc, 512k, 1024k, 2048k and 4096k.

I also created a virtual memory one for unexpanded 464 users - and if it does work fast enough, I can make a more optimal version for 128k users - the main difference is that a 128k user can cache 5 blocks of virtual ram at any one time where-as a 464 user cannot.

The virtual memory logic is waiting for me to complete the FileExists and FileDelete functions.   Also, can AMSDOS open more than one input or output file at the same time?

Anyone know how to do the following programatically in AMSDOS?  FileExists, FileSize and FileDelete.

Thanks

[zhulien]

https://github.com/PrimalNinja/Primal/blob/main/README.md

I haven't posted the code yet, waiting for @Prodatron as to whether i can include the Symbos includes or not...

I also cannot find a licence anywhere.  Might need to make my own up. (I can only find misspelled licenses)

[GUNHED]

An system independent / system overlapping API with Shell! That sound like a great plan!!!

In case you consider FutureOS (seriously) as candidate, of course I'm willing to help.
Which features may be of interest to you?
- You can use the complete main RAM memory area of &0000 to &9FFF (40 KB) for your API/Shell
- You can use the memory area of &A000-&B7FF (6 KB more) as buffers as long as you don't access OS functions for LOAD / SAVE data
- Expansion RAM can be banked in between &4000-&7FFF like usual. There is memory management for blocks of 16 KB.
- All RST entries are free for you and of course the interrupt entries too
- You can use all Z80 registers. Really all.

Let me know if you want to start with an implementation of your API/Shell for FutureOS then I will post here how to use the 12 PS_xxx functions you need. 

[zhulien]

@GUNHED thanks for that info, I have already added futureos to the build chain, and just need to code a few functions.  Actually very very few - but of course I need to debug my code - I haven't run it yet   but I have a good track record of making 'almost' working code first time.  The memory map I will make is just like you said.  I will check into Github soon (likely this weekend) and anyone is welcome to help - but I am happy to go along.  I want to make the driver model so that I can implement a couple of network card drivers for a game I am making.  Not a full TCP/IP stack, but an easy to use way to talk to a server.  I will leave TCP/IP and such to others.  As a test today, I bundled a 6502 emulator into the kernel, but... not sure it has a real use - it was ripped out of the sidplayer and modified to be relocatable.

The AMSDOS loader looks like this, likely 'almost' the same for FutureOS except the PS_ functions (Platform-Specific) need to be coded for each new platform.

load_ams.asm

Code Select Expand

;#dialect=RASM

ADDR_2KBUFFER equ #c000
ADDR_RAMTOP equ #a140 ; 40k + #0040 + 256 (stack size)
CAS_IN_OPEN equ #bc77
CAS_IN_CLOSE equ #bc7a
CAS_IN_DIRECT equ #bc83
CAS_OUT_OPEN equ #bc8c
CAS_OUT_CLOSE equ #bc8f
CAS_OUT_DIRECT equ #bc98
KM_READ_KEY equ #bb1b
KM_READ_CHAR equ #bb09
KM_WAIT_CHAR equ #bb06
SYSTEM_RESET equ 0
TXT_OUT_CHAR equ #bb5a

FILETYPE_BINARY equ 2
STACKSIZE equ 128

org #0040

; WARNING NO CODE FROM HERE IN THIS FILE

LOADER: jp Main ; loader is a platform dependent program loader

; header
ADDR_RELOCTABLE:dw 0 ; this isn't being relocated, so always 0
ADDR_VERSION: dw 1 ; version
ADDR_APICOMPAT: dw 1 ; API compatability ID
ADDR_REQMEMTYPE:db 1 ; required memory type
ADDR_PATCHTABLE:dw PatchTable
ADDR_JUMPBLOCK: dw JumpBlock ; pointer to the jumpblock
ADDR_ISR: dw 0 ; pointer to the ISR
ADDR_LOADER: dw 0 ; always 0 for loader
MSG_PRIMAL: db "PRIMAL", 0 ; type must be after the jump to main
db "Loader for Amstrad CPC", 0 ; description

include "load.asm"

; WARNING CODE BELOW HERE ONLY IN THIS FILE

; Memory Table Record Summary
; 0 = End of Table
; 1 = Non-Pageable block of RAM
; 2 = Pageable block of RAM
; 252 = Video RAM
; 253 = Reserved RAM
; 254 = ROM
; 255 = Extension Block (anything following an extension record is ignored)
MemTable:
db 1
dw END_OF_LOADER
dw #3fff

db 1
dw #8000
MemBlock1End: dw 0

db 2
dw #4000, #7fff

db 0 ; End of Block / can be patched to be an Extension Block
dw 0, 0

PS_RAMInit: ; initialise RAM
ld hl,ADDR_RAMTOP
ld sp,hl ; put stack at himem

ld de,STACKSIZE ; calculate new himem to be below the stack
and a
sbc hl,de
ld (MemBlock1End),hl
ret

PS_CanSave: xor a ; can we save to the boot device?
ret

PS_CharIn: call KM_READ_CHAR
ret c
xor a
ret

PS_CharOut: call TXT_OUT_CHAR
ret

PS_CharWait: call KM_WAIT_CHAR
ret

PS_CommandLine: ret ; get commandline parameters

; ------------------------- FileExists
; -- parameters:
; -- HL = filename address
; -- return:
; -- Z if TRUE if the file exists, NZ if FALSE
; -- corrupt:
; -- AF, BC, DE, HL

PS_FileExists: jp SysError ; platform specific fileexists
ret

; ------------------------- FileSize
; -- parameters:
; -- HL = filename address
; -- return:
; -- BC = filesize
; -- Z if TRUE, NZ if FALSE
; -- corrupt:
; -- AF, BC, DE, HL

PS_FileSize: xor a ; platform specific filesize
ret

PS_FileDelete: ret ; platform specific filedelete

; ------------------------- FileLoad
; -- parameters:
; -- HL = filename address
; -- return:
; -- Z if TRUE, NZ if FALSE
; -- corrupt:
; -- AF, BC, DE, HL

PS_FileLoad: push hl
push de
push hl
call SysStrLen
ld b,c
pop hl
ld de,ADDR_2KBUFFER
call CAS_IN_OPEN
pop hl ; hl now is the load address
pop de ; no need the filename anymore
jp nc, SysError

call CAS_IN_DIRECT
jp nc, SysError

call CAS_IN_CLOSE
xor a
ret

; ------------------------- FileSave
; -- parameters:
; -- HL = filename address
; -- DE = save from address
; -- BC = save length
; -- return:
; -- Z if TRUE, NZ if FALSE
; -- corrupt:
; -- AF, BC, DE, HL

PS_FileSave: push hl ; platform specific save
push de
push bc
push hl
call SysStrLen
ld b,c
pop hl
ld de,ADDR_2KBUFFER
call CAS_OUT_OPEN
pop de ; now the save length
pop hl ; now the save from address
pop bc ; no need the filename anymore
jp nc, SysError

ld a, FILETYPE_BINARY
call CAS_OUT_DIRECT
jp nc, SysError

call CAS_OUT_CLOSE
xor a
ret

PS_StrIn: ; gets a string input
ret

PS_StrOutHL: ; outputs a string pointed to by HL
StrOutHL_Loop1:
ld a,(hl)
or a
jr z,StrOutHL_Loop1end
push hl
call SysCharOut
pop hl
inc hl
jr StrOutHL_Loop1
StrOutHL_Loop1end:
ret

PS_Terminate: ; terminate elegantly
call SYSTEM_RESET
ret

END_OF_LOADER:
Then I have a separate memory driver for the extended memory, in fact I have lots of variants which I believe will likely just work for FutureOS without modification - since it is on a CPC too.

ams_256.asm

Code Select Expand

;#dialect=RASM

org #0000
relocate_start

; WARNING NO CODE FROM HERE IN THIS FILE

BIOS: jp Main ; BIOS provides platform dependent way to access hardware in a uniform way

; header
dw RelocationTable - BIOS
dw 1 ; version
dw 1 ; API compatability ID
db 1 ; required memory type
dw PatchTable
dw JumpBlock ; pointer to the jumpblock
dw 0 ; pointer to the ISR
dw 0 ; pointer to the component that loaded this
db "PRIMAL", 0 ; type must be after the jump to main
db "256k Banked Memory for Amstrad CPC", 0 ; description

include "mem.asm"

; WARNING CODE BELOW HERE ONLY IN THIS FILE

RAM_SEL_PORT_COUNT equ 15
RAM_BANK_START equ #4000
RAM_BANK_END equ #7FFF
RAM_BANK_SIZE equ #4000
RAM_SEL_PORTS: defw #7fc4, #7fc5, #7fc6, #7fc7
defw #7fcc, #7fcd, #7fce, #7fcf
defw #7fd4, #7fd5, #7fd6, #7fd7
defw #7fdc, #7fdd, #7fde, #7fdf

PS_BankCount: ld a,RAM_SEL_PORT_COUNT ; returns number of banks
ret

PS_BankSelect: ld hl,RAM_SEL_PORTS ; selects memory bank
ld b,0
ld c,a
add hl,bc
add hl,hl
ld c,(hl)
inc hl
ld b,(hl)
out (c), c
ret

PS_BankUnSelect:
ld bc,#7fc0 ; deselects memory bank (same as selecting bank 0)
out (c),c
ret

PS_BankStart: ld hl, RAM_BANK_START ; start of current memory bank
ret

PS_BankEnd: ld de, RAM_BANK_END ; end of current memory bank
ret

PS_BankSize: ld bc, RAM_BANK_SIZE ; size of current memory bank
ret

PS_Initialise: ret

RelocationTable:
dw relocate_count
relocate_table
relocate_end

END_OF_BIOS:
The Virtual Memory driver is a little different, does FutureOS work on a 64k machine?

ams_v64.asm

Code Select Expand

;#dialect=RASM

org #0000
relocate_start

; WARNING NO CODE FROM HERE IN THIS FILE

BIOS: jp Main ; BIOS provides platform dependent way to access hardware in a uniform way

; header
dw RelocationTable - BIOS
dw 1 ; version
dw 1 ; API compatability ID
db 1 ; required memory type
dw PatchTable
dw JumpBlock ; pointer to the jumpblock
dw 0 ; pointer to the ISR
dw 0 ; pointer to the component that loaded this
db "PRIMAL", 0 ; type must be after the jump to main
db "64k Virtual Memory for Amstrad CPC", 0 ; description

include "mem.asm"

; WARNING CODE BELOW HERE ONLY IN THIS FILE

RAM_SEL_PORT_COUNT equ 3
RAM_BANK_START equ #4000
RAM_BANK_END equ #7FFF
RAM_BANK_SIZE equ #4000
RAM_SEL_FILES: defw filename_7fc4, filename_7fc5, filename_7fc6, filename_7fc7, 0
filename_current: defw filename_7fc0

filename_7fc0: defb "mem_7fc0.bin",0
filename_7fc4: defb "mem_7fc4.bin",0
filename_7fc5: defb "mem_7fc5.bin",0
filename_7fc6: defb "mem_7fc6.bin",0
filename_7fc7: defb "mem_7fc7.bin",0

PS_BankCount: ld a,RAM_SEL_PORT_COUNT ; returns number of banks
ret

PS_BankSelect: ; selects memory bank
ld hl,RAM_SEL_FILES
ld b,0
ld c,a
add hl,bc
add hl,hl
ld c,(hl) ; bc = new filename
inc hl
ld b,(hl)

; first check if we already are in this memory
; if we are then just return otherwise
ld hl,(filename_current)
xor a
sbc hl,bc
ret z

push bc
; save current memory
ld hl,(filename_current)
ld de,RAM_BANK_START
ld bc,RAM_BANK_SIZE
call SysFileSave
pop bc
jr nz, VirtualMemoryError

; select new one
ld l,c
ld h,b
ld de,RAM_BANK_START
push hl
call SysFileLoad
pop hl
jr nz, VirtualMemoryError

; store the current bank
ld (filename_current), hl
ret

PS_BankUnSelect: ; deselects memory bank
; first check if we already are in this memory
; if we are then just return otherwise
ld hl,(filename_current)
ld bc,filename_7fc0
xor a
sbc hl,bc
ret z

; save current memory
ld hl,(filename_current)
ld de,RAM_BANK_START
ld bc,RAM_BANK_SIZE
call SysFileSave
jr nz, VirtualMemoryError

; select new one
ld hl,filename_7fc0
ld de,RAM_BANK_START
push hl
call SysFileLoad
pop hl
jr nz, VirtualMemoryError

; store the current bank
ld (filename_current), hl
ret

PS_BankStart: ld hl,RAM_BANK_START ; start of current memory bank
ret

PS_BankEnd: ld de,RAM_BANK_END ; end of current memory bank
ret

PS_BankSize: ld bc,RAM_BANK_SIZE ; size of current memory bank
ret

PS_Initialise: ld hl,RAM_SEL_FILES

ld hl,RAM_BANK_START ; clear memory where banking occurs
ld de,(RAM_BANK_START+1)
ld bc,(RAM_BANK_SIZE-1)
ldir

PS_InitialiseLoop:
ld e,(hl)
inc hl
ld d,(hl)
inc hl
ld a,e
or d
ret z

push hl

ld l,e
ld h,d
push hl
call SysFileExists
pop hl
jr z, PS_InitialiseSkip

push hl
call SysFileDelete
pop hl

PS_InitialiseSkip:
ld de,RAM_BANK_START
ld bc,RAM_BANK_SIZE
call SysFileSave

pop hl
jr nz, VirtualMemoryError

jr PS_InitialiseLoop

VirtualMemoryError:
call SysStrOutPC
db "Virtual Memory Error.", 0
ret

RelocationTable:
dw relocate_count
relocate_table
relocate_end

END_OF_BIOS:
These files each have includes that are the platform independent code, such as load.asm includes the relocation and patching code.  It allows me to grow the API jumpblocks over time but not break compatability with other applications by patching ranges of supported functions rather than individual API calls.  I believe that jumpblocks are more coder friendly than the CP/M load a function in c method.  I have no restrictions on register usage - but I will find out of any underlying platforms do as I go.

[zhulien]

@GUNHED for FutureOS, do i need to setup my own stack or just use it whereever it is?

[zhulien]

Here is a FOS version of the loader, I only put entry/exit documentation in the AMSDOS version for now - but I will add it to a text file or wiki page.  I use Z flag for true and NZ for false (it reads better).

Code Select Expand

;#dialect=RASM

ADDR_RAMTOP equ #9fff
STACKSIZE equ 128

org #0040

; WARNING NO CODE FROM HERE IN THIS FILE

LOADER: jp Main ; loader is a platform dependent program loader

; header
ADDR_RELOCTABLE:dw 0 ; this isn't being relocated, so always 0
ADDR_VERSION: dw 1 ; version
ADDR_APICOMPAT: dw 1 ; API compatability ID
ADDR_REQMEMTYPE:db 1 ; required memory type
ADDR_PATCHTABLE:dw PatchTable
ADDR_JUMPBLOCK: dw JumpBlock ; pointer to the jumpblock
ADDR_ISR: dw 0 ; pointer to the ISR
ADDR_LOADER: dw 0 ; always 0 for loader
MSG_PRIMAL: db "PRIMAL", 0 ; type must be after the jump to main
db "Loader for FutureOS", 0 ; description

include "load.asm"

; WARNING CODE BELOW HERE ONLY IN THIS FILE

; Memory Table Record Summary
; 0 = End of Table
; 1 = Non-Pageable block of RAM
; 2 = Pageable block of RAM
; 252 = Video RAM
; 253 = Reserved RAM
; 254 = ROM
; 255 = Extension Block (anything following an extension record is ignored)
MemTable:
db 1
dw END_OF_LOADER
dw #3fff

db 1
dw #8000
MemBlock1End: dw 0

db 2
dw #4000, #7fff

db 0 ; End of Block / can be patched to be an Extension Block
dw 0, 0

PS_RAMInit: ; initialise RAM
ld hl,ADDR_RAMTOP
ld sp,hl ; put stack at himem

ld de,STACKSIZE ; calculate new himem to be below the stack
and a
sbc hl,de
ld (MemBlock1End),hl
ret

PS_CanSave: xor a ; can we save to the boot device?
ret

PS_CharIn: ret

PS_CharOut: ret

PS_CharWait: ret

PS_CommandLine: ret ; get commandline parameters

PS_FileExists: ret ; platform specific fileexists

PS_FileSize: ret ; platform specific filesize

PS_FileDelete: ret ; platform specific filedelete

PS_FileLoad: ret ; platform specific fileload

PS_FileSave: ret ; platform specific filesave

PS_StrIn: ; gets a string input
ret

PS_StrOutHL: ; outputs a string pointed to by HL
StrOutHL_Loop1:
ld a,(hl)
or a
jr z,StrOutHL_Loop1end
push hl
call SysCharOut
pop hl
inc hl
jr StrOutHL_Loop1
StrOutHL_Loop1end:
ret

PS_Terminate: ; terminate elegantly
ret

END_OF_LOADER:

[zhulien]

The RAM types are there to allow the system to draw memory maps of systems, not only to control what goes where.  Only type 1 and 2 are really important for loading code - whether something is in an always paged in block (type 1) or in a pageable block (type 2) - so of course memory drivers need to load into type 1. An extension block can be used to point to another list of memory blocks added by a later loaded component.

[zhulien]

Some developments notes that I use as I progress - shows current development progress.   <-----  means it is implemented by something on the left, usually an indiciation that it is not platform specific.

https://docs.google.com/spreadsheets/d/14JQa3cTEd9fIz9lyoQRkzVc5xBz5FhEdr_DC41xPkJs/edit?usp=sharing

Commenting is enabled.

[zhulien]

github is online with source (minus Symbos includes for now)

https://github.com/PrimalNinja/Primal

[zhulien]

And Exidy Sorcerer:
http://www.bitsavers.org/pdf/exidy/Exidy_Sorcerer_2_Technical_Manual_Dec1979.pdf

I read this, it is a good read but unfortunately doesn't have a lot of programming info.  I did see that Sorcerer can run CP/M but it seems it also had it's own OS too.

[Animalgril987]

Is the following website any help at all?

http://www.trailingedge.com/exidy/

[GUNHED]

@GUNHED for FutureOS, do i need to setup my own stack or just use it whereever it is?

In FutureOS the space from &BE00 to &BFFF is reserved for the stack.

In case you swtich to Interrupt Mode 1 (IM 1) and catch the interrupt at &0038 then you can also use the memory area from &BD00 to &BDFF for what ever you want.

You can leave the SP register how it is and just use the about 500 bytes for the stack, that should be fine.
In case you change the stack it doesn't matter at all.
Because to leave an application you would code:
LD HL,TUR_E
JP ROM_D
This will bring you back to the Desktop and the SP register will be reloaded anyway.

[zhulien]

Added the Symbos libraries and VZ300 platform, you can now build - I am yet to test anything though and will let you know when something is tested.