Mega 65 Port (Commander X16 see #89)

[gitjeff2]

In addition to the native C128 port, support for the Mega 65 and the Commander X16 would be positively amazing. The former is basically a beefy Commodore C65 while the latter is a lot closer to an evolved C64 on an open platform.

[fachat]

Lacking hardware to test on it, I can only hope for 3rd party contributions

[mist64]

André,

We have an emulator for the X16 at:

https://github.com/commanderx16/x16-emulator

Michael :-)

[jsyk]

Hello Andre,
I could donate you a CX16-compatible hardware, if you are interested in a port to a new platform.
It would be my clone X65-SBC computer, which can run CX16 ROMs directly.
Let me know what do you think.
Jaroslav

[fachat]

Ok, I see there is support for the X16 port :-)

I've looked up the X16 memory map. Unfortunately, with its low memory without banking, and fixed ROM in the top 16k this is similar to the pet32k architecture. If you have to put all the GeckOS code into the low 39k there really is not much space left for the application itself.

[And the ROM needs to have a changeable interrupt vector so GeckOS can take over the interrupt, but I assume that is the case]

(For ref I looked it up here https://github.com/X16Community/x16-docs/blob/master/X16%20Reference%20-%2008%20-%20Memory%20Map.md and here https://www.c64-wiki.com/wiki/Commander_X16#Memory_and_Operating_System )

I wonder how much sense it actually makes.

On the other hand, it could be an option to put GeckOS into the X16 ROM. This could be feasible, with say the kernel, and lib in the banked system ROM and support programs in the banked RAM. [Is the X16 ROM in-circuit programmable?]

Nevertheless, zeropage is still shared, and stack needs to be copied to achieve reasonable numbers of tasks/processes to run.

[fachat]

Add. comment: some support programs (e.g. SD-card filesystem, USB) will need more than the 8kB that is available as banked memory. These need to be put in ROM I'd guess, but at least require interrupt routines to map back to kernel etc.

[jsyk]

Hi André, I am looking for an Operating System for my X65-SBC computer (github link in the previous message) which is utilizing the 16-bit 65C816 processor. I started the hobby development of that system a year ago as a clone of CX16 with 65C02. But during the development I realized that by using the 16-bit 65C816 CPU the computer becomes more performant, easier to code for, and much more interesting. (It is still backward compatible with CX16, their ROM runs without modifications.) Also, the original CX16 ROMs are not "free" software, but they are proprietary licensed and the license does not allow running them on anything else than the original hw. I want to respect that, even if I don't like it. All your comments regarding the CX16 are correct. But the 65C816 CPU overcomes the problems even without an MMU. The stack can be relocated anywhere in the first 64kB of RAM and it can have any size up to 64kB; so you can give a process its own stack just by switching the SP. Also the Zero page, now called Direct page, can be relocated anywhere in the 64kB, so you can context-switch easily. The processor can address up to 16MB of memory in 64kB banks (segments), and you have an independent bank register for code and memory. (But I am sure you know all this already.) In the end it is a similar architecture like the 8086 used to be with segments addressing etc. The memory in my X65-SBC is all RAM, so you don't have to worry about ROM/RAM split, and it is all accessible from a host PC for development via built-in ICD. (On boot the initial code is loaded from SPI-Flash by the system FPGA.) Currently I am porting the OF816, an open-forth for '816, and it runs fine with the user interface being available on the UART of the system. (see https://hackaday.io/project/194866-x65-sbc) I am coding a console interface (video terminal with keyboard), a kind of BIOS support for the OF816 code. Did you consider porting GeckOS to 65C816? What would need to change? The relocatable o65 format supports the '816 I think, but what about the XA ? Regards, Jaroslav.

…

On Thu, Mar 28, 2024 at 11:18 AM A. Fachat ***@***.***> wrote: Add. comment: some support programs (e.g. SD-card filesystem, USB) will need more than the 8kB that is available as banked memory. These need to be put in ROM I'd guess, but at least require interrupt routines to map back to kernel etc. — Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANKH2DKXXQ3OQC7T7QGAA3Y2PN7JAVCNFSM4MQFUIL2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSGQ4DINZZGAYA> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jaroslav Sykora http://www.jsykora.info/

[fachat]

Currently GeckOS is a 6502 operating system. It does not use any of the 65816 features even if it runs on a system that has it.

Having said that, I have built my own 65816 system (see http://6502.org/users/andre/upet/index.html or http://6502.org/users/andre/ultipet/index.html ) and a mid- to long-term goal is to port it to the 65816 too (even though my own systems have memory mapping that supports using this amount of memory even in 6502 mode). But before that at least the new buffers/channels/ports need to replace streams/send+receive, and I want to have C128 port for the Commodore 128's 40th birthday next year...

What would need to change:

• First of all we need to define a memory model. Most likely something like kernel, and support programs in bank0. Any other tasks in other banks, with zp/sp separate per bank in bank0. The kernel could then allocate a new bank for each program, until all program banks are used, and then double-use banks like it does a single bank right now.
• lib6502 would need to be present in every bank
• The task tables are built to be efficient, so task ID is an index into the task table, and thus the table cannot exceed 256 bytes. Currently there actually are two tables with 13 byte entries, so at max 19 tasks. Re-organizing the tables could increase this, but probably not needed for a start.
• In the arch/*/kernel section new code needs to be created to map programs into other banks, and switch appropriately ("memtask" and "memsys" mostly), along with other init stuff.
• Send/receive and streams (resp. then buffers/channel/ports) potentially need to be adapted to be able to copy data between banks. Currently the CS/A port (the only one with real mapping right now) maps in pages from each task into the CPU address space while in the kernel and copies data over if needed.

As the send/receive/streams transition is highly disrupting, I'm actually inclined to go to version 3 when this is done. For more details see https://github.com/fachat/GeckOS-V2/blob/master/GeckOS-NG-Buffers.adoc

On the other hand, making plans allows to take a 65816 system into account when re-doing the buffers....

[fachat]

P.S.: xa supports the 65816 just fine. o65 too, so no problem there.

Only one thing that may be interesting to note: there are a couple of program that access the stack with
LDA $0101,X - this does not work on the 65816 anymore if a program is running in another bank but bank 0.

It would be helpful if we could add a flag to o65 to mark that. Otherwise it could be a gamble to run 6502 programs on a 65816 version of GeckOS.

Maybe other ramifications come from emulation vs. native mode...: http://www.6502.org/tutorials/65c816opcodes.html

[jsyk]

Ok, thanks for the feedback. I should have a detailed look at Geckos to understand more details... I like your idea of how to put basically 8-bit processes into the 16-bit system. It reminds me the .COM files (as opposed to .EXE) in MS-DOS where they also handled just 64kB programs with the segment configuration CS=DS. I think this was done as a migration path from 8-bit 8085 -> 16-bit 8086. Are there other applications compatible with lib6502 / geckos than what is present in the repository?

…

On Fri, Mar 29, 2024 at 9:32 PM A. Fachat ***@***.***> wrote: P.S.: xa supports the 65816 just fine. o65 too, so no problem there. Only one thing that may be interesting to note: there are a couple of program that access the stack with LDA $0101,X - this does not work on the 65816 anymore if a program is running in another bank but bank 0. It would be helpful if we could add a flag to o65 to mark that. Otherwise it could be a gamble to run 6502 programs on a 65816 version of GeckOS. — Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANKH2GFUTC6O7EJYVJN7S3Y2W6VDAVCNFSM4MQFUIL2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSG43TAOJQGY4A> . You are receiving this because you commented.Message ID: ***@***.***>

-- Jaroslav Sykora http://www.jsykora.info/

[fachat]

Changing GeckOS into a true 65816 operating system would be ... challenging. It wouldn't probably be GeckOS anymore. But you never know.

For now I would be happy if I would be able to run multiple 6502-type processes in different banks, with each having most of the bank for themselves. Maaaayyyybeeee with a driver / interface that would allow far accesses for 65816 programs to other banks - I should probably plan in a bank management (allocate / free banks)....

As for other lib6502 programs - you would probably have to look at the Lunix ecosystem. Otherwise I am not aware of other software using lib6502 unfortunately.

For anything more advanced - an editor is high on my list - the terminal code needs to be refined too, and more standard terminal control codes defined and implemented (probably along with something along a "curses" library....). Probably a source code solution "term.a65" would be a good idea, as this would allow me to gradually evolve and change things "behind the scene"... :-)

[fachat]

For reference the extension of o65 to mark absolute stack address patterns: fachat/o65#4

[fachat]

For easier separation of topics, let's keep Mega65 discussion in this issue, and Commander X16 in #89