-
Notifications
You must be signed in to change notification settings - Fork 28
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.
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
C128 version? #95
Comments
Original comment by
|
Original comment by
|
Original comment by
|
Original comment by
|
Original comment by
|
Original comment by Attachments: |
Original comment by
|
Original comment by |
Original comment by |
Seems to be one at http://forth128.blogspot.se/ |
Pretty cool! Of course there are some changes since August. Is there any download? |
I had the same idea, and got it sort-of working fairly without too many changes; I've put a work-in-progress branch up at https://github.com/rhalkyard/durexforth/tree/c128-port. So far, both 80 column and 40 column text modes work (including switching between them with escape-X), and it can load and compile source and operate interactively. I've added Eventually it would be nice to support both the C64 and 128 in a single codebase. Would it be reasonable to add a built-in word to determine the platform that we are running on, so that the same code can do the right thing on both systems? I also have a Plus/4 sitting around. If I get bored this winter I might try porting to that too ;) |
Hi! |
Thank you! I'm impressed with how easy it was to get it working - it's a very easy-to-understand codebase.
|
For your question, |
It also works in C64 mode, how about "?vdc"? |
Pushed a few more changes that got
That might be useful to have too, but we will also need to be able to identify a C128 running in native mode. Hopefully most of those checks can be done in fairly low-level code, but, e.g. graphics routines will need to know about the different memory layout and bank controls on the native 128.
The VDC also has its own unofficial graphics mode that's even higher resolution (640x200 or 640x480 interlaced); might be fun to add support for that sometime too! EDIT: never mind about my memory layout comment; it is indeed possible to use |
In the process of this, I have added some new words This lets us handle the differences between the C64 and C128 at compile time - only the code appropriate to the machine gets compiled, so (aside from the extra dictionary space these words take up) there will be no runtime cost in speed or code size to supporting both systems. The implementation and some examples in I realise that adding these words to the standard environment consumes almost all the remaining cartridge space, but it will make supporting both systems (or potentially, having full-featured and "lite" variants of libraries) much easier. |
Humm, yeah I must admit I'm not really a fan of adding Maybe the differing words could be moved out to their own files? Then the problem could even be solved in the Makefile, by having two separate builds for c64 and c128? |
That's reasonable; it was fun implementing them anyway, and I think that with how few changes were actually required, your idea is a better one. If you don't mind me doing so, I'll do some refactoring of the makefile to support it. On the topic of fun things, the 128 version makes playing with graphics a delight - since the VIC and VDC are completely independent, you can leave the VIC in hi-res mode while the interpreter runs on the VDC, so you can interactively play with graphics words and see their effects immediately. It's one thing to do it in an emulator, but there's a certain magic to seeing it on a pair of CRTs connected to a real machine :) |
Code-wise, I see only two roadblocks to considering 128 support fully functional. On the simple side, float.fs still needs to be modified to work with the 128's BASIC routines. I haven't touched it yet because I don't entirely understand how it avoids corrupting the stack - the floating-point accumulators in 128 BASIC are slightly closer to the start of the stack than on the 64, so there would be greater risk of overwriting valid stack values. Some advice on how it works on the 64 would be appreciated. And then there's a bug that stopped me from sleeping last night. I don't expect you to have an answer for me or anything, but I figure that if I write it all down, it'll at least help me organise my thoughts, and if I'm really lucky, someone smarter than me will see it and have an idea. On the 128, the first character of the line following an The strange thing is, I've spent hours examining the code path where this happens ( If we have some source that looks like this,
as far as I can understand it, the sequence of events are as follows:
It gets even stranger when testing with different drives - with a 1571 the problem is sporadic and almost always manifests as a dropped character rather than a garbled one, but a 1541 will always return a garbage character in this case. I first noticed this running in VICE and wondered if it was an emulator issue, but when I tried it on my real 128 with real drives, the issue manifested in the exact same way. Until I can get to the bottom of it, this bug is a bit of a showstopper, but it is possible to work around the issue by following each
|
Stepping through with the Vice monitor might be illuminating. Just trying to help you sleep ;) |
This may help: |
About float.fs: It does not really work on C64 either, so don't worry about it! It's just a fun, undocumented hack. I added a comment to underline that further. About |
By the way, what is the exact repro? |
Ah, that's good to know. funnily enough, the C128's ability to remap the zero page might make that kind of thing easier to work with - with some clever memory-map juggling we could have almost the whole zero page dedicated to the Forth stack.
I've managed to reproduce the issue with a simple program that alternates reading from two different files. The code and a brief writeup are at https://github.com/rhalkyard/c128-chkin-bug. I'll update that repo as I continue to dig into it. |
Try using $00 as the secondary address for both files, look for the ASCII value of the byte read in location 512 ($200) |
Maybe you need to specify drive number when opening the files? I have some
vague memory that the C128 is weird or particular about this.
Not that it should matter...
…On Mon, 14 Dec 2020 at 03:37, Whammo ***@***.***> wrote:
Try using $00 as the secondary address for both files.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#95 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAY34OYMVC62ZWSWHDVRC3DSUV26XANCNFSM4BZPCYMA>
.
|
@rhalkyard I think I got it working by calling |
Calling |
clrchn calls untalk |
|
Simply amazing! Soon, the best programming language implementation for the C64 will be the best programming language implementation for the c128! Thank you all! |
NO! AND, you must disconnect -- explicitly -- from an active file-channel before you close that file. That's true for all models of Commodore 8-bit computers and all models of drive units. If it had happened to work without |
I stand corrected! I can't remember where I picked up that bit of misinformation, but I'd seen it done that way so often, I'd never thought to question it. |
Per Greg King's comment on issue jkotlinski#95, this is not a bug, and CLRCHN should be used on both C64 and C128.
Thank you @greg-king5 for sharing knowledge! Much appreciated! |
! |
@greg-king5 a question about this "AND, you must disconnect -- explicitly -- from an active file-channel before you close that file." Just to clarify. First call |
It's the other way around. You can think of the actions in terms of functional blocks. "Openning a file", "connecting to a file", and "getting/sending bytes" are three blocks. The later blocks should be nested completely inside the earlier blocks. It's similar to nested code blocks in a lot of programming languages, such as C, Python, Java, Ruby.
|
Another thing to consider is that people will want to use DurexForth on devices other than Commodore's floppy drives. There are hard drives and solid state drives. There are devices that plug into an expansion connector, such as IEEE adapters, the Lt. Kernel hard drive, RAM drives, the IDE64 hard drive adapter, and 80-column display adapters. There were switching hubs that allowed a kind of "Network-Attached Storage" (used in business offices and classrooms). We can't know how those devices will react to a program that takes shortcuts (leaves out a function call), or calls functions in a wrong order. It's best not to take chances. |
Further work here: #478 |
Original issue reported on code.google.com by
[email protected]
on 27 Oct 2012 at 11:59The text was updated successfully, but these errors were encountered: