Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Commander X16 Port (I would help) #216

Open
Serentty opened this issue Sep 21, 2019 · 37 comments
Open

Commander X16 Port (I would help) #216

Serentty opened this issue Sep 21, 2019 · 37 comments
Labels
help wanted

Comments

@Serentty
Copy link

So, I know that making and maintaining a port to anything is a big commitment, so if you would rather not, that's fine and you can go ahead and close this. That said...

David Murray (The 8-Bit Guy) is designing a new computer called the Commander X16 meant for retrocomputing enthusiasts, people learning programming, and anyone else who would want such a system. It's based around the 65C02 (possibly being upgraded to the 65816 before release), and is 6502-compatible. It comes with BASIC in ROM, and while this is okay, BASIC is really starting to show its age and it would be nice to have another language available that is still well-suited to an 8-bit CPU, and Forth is one of the best options. That's why I'm interested in seeing this ported over, and would love to help make that happen.

The X16 is strongly inspired by Commodore designs, and it is compatible with the C64 in many ways, including having a compatible KERNAL jump table ($FFD2 is still CHROUT, and so on). The video chip is also capable of 40×25 text at 16 colours, just like the VIC-II. So, a lot of stuff would just work out of the box.

I would estimate this as being about as difficult as a port to the Commodore 128 would be, and I would be willing to do most of the work, just asking some questions here and there.
@polluks
Copy link
Contributor

polluks commented Sep 21, 2019

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

@jkotlinski
Copy link
Owner

jkotlinski commented Sep 21, 2019 via email

@Serentty
Copy link
Author

Thanks! Do you have an IRC or anything like that for questions?

@jkotlinski
Copy link
Owner

jkotlinski commented Sep 21, 2019 via email

@Serentty
Copy link
Author

Okay. I'll leave comments here on this thread if I have questions, and possibly open other issues if I find problems that aren't restricted to just the port.

@kghultland
Copy link

I am also trying to port the Durexforth code to the CX16 and I do have a couple of questions regarding address $1234 and the f_no_tail_call_elimination.

Address $1234 (4660) is in the middle of the BASIC RAM memory, is it possible to move that address to another place? It feels like a "randomly" selected address and as such, I am worried that the code might eventually grow to make the memory at $1234 being a part of Forth commands.

As my 6502 assembler knowledge is a bit rusty after 35 years I have a problem following the code that deals with the $1234 address as well as the purpose of the F_NO_TAIL_CALL_ELIMINATION flag.
The other flags (F_IMMED and F_HIDDEN) are clear to me.

I feel that the port should be quite straightforward once I changed the code that deals with the C64 zero-page, fixed addresses in the ROM and the usage of hardware registers/flags/chips.

@jkotlinski
Copy link
Owner

Hi! I added comments to explain purpose of $1234 and F_NO_TAIL_CALL_ELIMINATION. I hope it clears things up. Let me know if there are other questions! Thanks for asking!

@kghultland
Copy link

Unfortunately, I am still having problems and it seems to be related to keyboard input and possibly the stacks which brings me to the LSB/MSB stacks

I am trying to understand the MSB and LSB comments and wonder if you can clarify them?

MSB = $73 ; msb stack is [$3b, $72]
LSB = $3b ; lsb stack is [3, $3a]

@jkotlinski
Copy link
Owner

jkotlinski commented Oct 9, 2019 via email

@kghultland
Copy link

So, in essence, all of the zero-page from $03 to $72 (110 bytes) will be overwritten by the
parameter stack?

I sure hope that the CX16 Kernel don't mess with the BASIC zero-page area :D

@jkotlinski
Copy link
Owner

jkotlinski commented Oct 9, 2019 via email

@jkotlinski
Copy link
Owner

jkotlinski commented Oct 9, 2019 via email

@kghultland
Copy link

Stupid me :D The problem I had was not with the .asm code
as the changes I made there seems to work.

The problem is because I didn't realize that the code tries to load the
base.fs code before starting the interpreter and that is what fails.

@Kroc
Copy link

Kroc commented Oct 14, 2019

As an aside to this, I'm toying with writing a Forth for C64/X16 with more of a focus on usability. DurexForth is very high quality program, but Forth itself is needlessly cryptic. I'm prototyping something now that uses single bytes for the stack instead of 16-bits per cell, e.g. "dup" dupes the top two bytes, "dup.w" dupes the top two words (16-bits), if necessary "dup.l" could be available for longs (32-bits). I'm also changing some of the syntax to be a little more accessible to people who are not already Forth programmers such as "\n" for a carriage-return instead of "CR"

@jkotlinski
Copy link
Owner

jkotlinski commented Oct 14, 2019 via email

@kghultland
Copy link

Another update, the CX16 emulator does not support reading from or writing to the normal hard disk directory on other KERNEL commands than LOAD and SAVE. So I spent the last week trying to debug code that will work on real hardware :p

What I need to do is to put the files in a SD-card image and read the data from there... :) Well at least this debugging made me understand how Durexforth works under the hood...

@Kroc
Copy link

Kroc commented Oct 14, 2019 •
edited
Loading

Yeah, the X16 emulator hijacks device no.1 with native code!

@Kroc
Copy link

Kroc commented Oct 15, 2019

I would be interested in helping with this if I could be assigned to improving usability. E.g. better error messages, adding an optional stack overflow/underflow checking mode, providing documentation etc.

@jkotlinski
Copy link
Owner

jkotlinski commented Oct 16, 2019 via email

@Kroc
Copy link

Kroc commented Oct 16, 2019

That all depends where that's happening; both @Serentty and @kghultland appear to be making ports, but their changes are not public, so I don't know if they've forked the code-base entirely, or intend to add the X16 support as a compile-time option and send the changes back to you. I'd much rather we work on a single repo as it's not unreasonable to be able to support the C64 and X16 with the same code base.

@jkotlinski
Copy link
Owner

jkotlinski commented Oct 16, 2019 via email

@kghultland
Copy link

The real changes this far are small, mainly removed references to the C64 Hardware, fixed some use of extra undocumented 6502 instructions and added some extra code to help me debug the core
and now adding some extra code to assist the compilation of the .fs files. This code that I only add to help me debug is not needed once it builds OK but could be retained if I compile with a -debug option.

The base.fs file compiles ok until it starts to include other .fs files, the error I am at now is in the asm.fs file.

After I have managed to find the reasons for the .fs commands compilations failing we will have to decide if we want this as a fork or if we just want a compile-time flag for the CX16.

Once it comes to implementing graphics functions using the "Vera" chipset and sound I am sure that I will need help :) But that code is written in Forth and Forth compiled assembler code so that will be a lot easier to do.

@jkotlinski
Copy link
Owner

jkotlinski commented Oct 16, 2019 via email

@Kroc
Copy link

Kroc commented Oct 16, 2019

The ROM is getting drawing commands added to it at the moment, so you may not have to do much writing directly to hardware when the ROM will already have line-drawing primitives to hand :)

@jkotlinski
Copy link
Owner

@kghultland Let me know if you would like some debugging help. It would be fun to help out!

@jkotlinski
Copy link
Owner

I notice that this thread has been silent for a while.
FYI I just made a new Forth which should be far easier to port to the X16: https://github.com/jkotlinski/acmeforth

@polluks
Copy link
Contributor

polluks commented Nov 26, 2019

Wow!

@kghultland
Copy link

I am still working on it in my spare time, unfortunately, my spare time has been low the last couple of weeks because of me finishing off a consultant assignment. My main stumbling block at the moment is the limitations of the emulator, for now, to write to files with other Kernel commands than the SAVE call.

I am going to look at Acmeforth as well but I think that having the Forth interpreter/compiler running natively is more in line with the visions of this new CX16 retro computer :D

@Kroc
Copy link

Kroc commented Nov 27, 2019

I've been noodling with an 8-bit Forth-like for the X16 as a sort of self-bootstrapping method of doing a scripting language on the system.

For example, lets say that I want to read in a text file, do a load of rather complex analysis and compression and write out a new binary; in assembler, this would be a long and arduous bit of development and would still be inflexible in the end. BASIC is problematic in that it undergoes total spaghettification as soon as your program grows beyond a certain point of complexity.

Forth is pretty much the lowest level, minimal language you can implement quickly that will give you the speed, compactness and flexibility you need to do scripting tasks on the system.

But Forth was 16-bit because it was invented on an 16-bit minicomputer. A native 8-bit Forth is shockingly less complex to write; and notably simpler with the benefit of 65C02 opcodes:

E.g. the store (!) word:

store:
        lda pl_stack+2, x       ; get value to store (3rd byte)
        sta (pl_stack, x)       ; store via the address on the stack

        inx                     ; consume...
        inx                     ; three...
        inx                     ; bytes

        rts

And executing the word atop the stack:

execute:
        ; we must reduce the stack by 2 bytes before we jump!
        inx
        inx
        ; 65C02: do a jump directly from the parameter stack,
        ; with +2 to compensate for already having popped the stack
        jmp (pl_stack+2, x)

@jkotlinski
Copy link
Owner

jkotlinski commented Nov 27, 2019 via email

@Kroc
Copy link

Kroc commented Jan 20, 2020

I've named my project for an 8-bit native Forth-like -- https://github.com/Kroc/pling -- though you should disregard the existing code, it's all being redone. I've opened a discussion thread if anybody here would like to contribute ideas regarding what an 8-bit native Forth should be like: https://github.com/Kroc/pling/issues/1

@Serentty
Copy link
Author

Two years? Well, my words were certainly bolder than my effort. :D

@jcolivo
Copy link

jcolivo commented Jul 21, 2021 •
edited
Loading

It was only after some time I came to think the benefits of being compatible with Starting Forth and the Forth standard documentation + test suites outweighed cool non-standard features.

@jkotlinski: I am late to this conversation, but I thank you for this. I just discovered forth earlier this year, and it has become my main programming language. I love the fact that I have a high quality ANS Forth 2012 version for my C64, which I use everyday.

I thank you and your team for the great work!

@jkotlinski
Copy link
Owner

@jcolivo thank you for the kind words! :)

@jkotlinski
Copy link
Owner

@jcolivo sorry for the necropost. I was wondering, may I add your words to Testimonials section in README.md?

@jkotlinski
Copy link
Owner

Is the X16 still a thing, or did public interest wane?

@pzembrod
Copy link

pzembrod commented Sep 13, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@Kroc @Serentty @jkotlinski @polluks @jcolivo @pzembrod @kghultland