12 minutes ago, pzembrod said:
That won't fly in many cases. E.g. cc64 would exhibit abysmal compile speeds if I were to swap out significant parts of the compiler code to and from SDCard.
Then what will you do on the X8?
(new title): Hard decision, but the answer is pretty clear.
(new title): Hard decision, but the answer is pretty clear.
Then what will you do on the X8?
(new title): Hard decision, but the answer is pretty clear.
4 minutes ago, x16tial said:
Then what will you do on the X8?
I'll wait for more info and decisions from the project owners, and then decide what will be feasible. If the BASIC at $8000-$BFFF assumption holds, then VolksForth likely will be. For cc64 I'd have to overwrite the BASIC interpreter, and it would still be a close call.
(new title): Hard decision, but the answer is pretty clear.
On 8/22/2021 at 9:54 PM, x16tial said:
As attached as we all are to the X16, the X8 is just the better idea.
As others have pointed out before: Things aren't as clear as you believe them to be.
(new title): Hard decision, but the answer is pretty clear.
1 hour ago, pzembrod said:
That won't fly in many cases. E.g. cc64 would exhibit abysmal compile speeds if I were to swap out significant parts of the compiler code to and from SDCard.
I believe this to be very true.
Switching RAM bank in X16 is the time it takes to write a value to a zero page address, i.e. 3 clock cycles = 375 ns @ 8MHz.
Virtual RAM bank switching would require you to first write the current bank values to disk (8 kB) and then read the new bank values from disk (also 8 kB).
In this thread, @Michael Steil commented the theoretical max throughput of the file system - about 13 kB/s if using (the KERNAL's) byte by byte operations, or 140 kB using the DOS routine macptr (I haven't looked closely on that, but it sounds interesting as the programs I've made have a throughput close to 13 kB/s).
https://www.commanderx16.com/forum/index.php?/topic/346-how-fast-will-sd-card-access-be-on-hardware/#comment-2223
Let's assume you would actually achieve both a read and write speed of 140 kB/s. First writing, and then reading 8 kB would take like 0,11 seconds. At 13 kB/s it would take about 1.23 seconds, by the way.
0.11 seconds is quick, but compared to X16 bank switching it's very slow. In fact, you could make about 293,000 X16 bank switches in the time it takes to do one virtual disk based bank switch (assuming read/write speed of 140 kB/s).
This doesn't mean that the X8 is useless. It means that the X8 and X16 requires fundamentally different thinking when you make programs. And some programs that need to use banked RAM a lot will be virtually impossible to port from X16 to X8.
I would certainly miss the real banked RAM of X16 if this project ended up being the X8 (only). The banked RAM is what opens so many opportunities for interesting 8 bit programming.
(new title): Hard decision, but the answer is pretty clear.
Luckily David had confirmed that the X16 is going ahead, so "X8 only" is not one of the options on the table.
Note that for data, if one is willing to sacrifice video capabilities, you can readily use Video RAM for data storage. It would be just like a small GEORam ... write the high byte of the address to the video page register, the page appears at $0400. If X8 load into Video RAM works, that's where I am going to put my Block files in the X8 version of xForth.
(new title): Hard decision, but the answer is pretty clear.
4 minutes ago, BruceMcF said:
Note that for data, if one is willing to sacrifice video capabilities, you can readily use Video RAM for data storage. It would be just like a small GEORam ... write the high byte of the address to the video page register, the page appears at $0400. If X8 load into Video RAM works, that's where I am going to put my Block files in the X8 version of xForth.
Now this is a fun idea! Hadn't thought about that ...
(new title): Hard decision, but the answer is pretty clear.
4 hours ago, pzembrod said:
As others have pointed out before: Things aren't as clear as you believe them to be.
Of course they aren't. And I already said that assumptions are being made. But that could be easily remedied. By giving us access to all of the info and the emulator. This isn't being done and is the source of my frustration.
This board might be less trafficked than the facebook group, but I'd argue the stronger supporters are here, where else is there software being released for the platform? Of which, myself, I've released some and have more in the works.
I immensely appreciate what the team has done so far. But we're ready, willing and able to pony up real cash for this/these products.
We're being asked if we want one of the said products, but we're being denied access to most of the information about it.
How is that not frustrating?
(new title): Hard decision, but the answer is pretty clear.
2 hours ago, pzembrod said:
Now this is a fun idea! Hadn't thought about that ...
My idea has always been to have block files as 8K segments of loadable files, with the base block number implied in the filetype, .B00 to .BFF, for up to 2MB in a single block space. The C64 version would load a single block segment underneath Basic ROM, access to another block in the segment would be straightforward, and if another block segment is referenced by the BLOCK word, copy from the block buffer to the block segment in RAM if the block buffer dirty bit is set, SAVE the block segment if its dirty bit is set, and load the desired block segment.
And then in the CX16, perhaps four to eight High RAM segments allocated to a LRU stack of Block segments, so a lot less potential for block thrashing.
The imagined High RAM usage is a bit of a three ring circus, with the dictionary contained in a chain of High RAM segments, the BLOCK word looking at the current block buffers, if they are not the requested one looking at the current block segments, loading the required one over the Least Recently Used one if necessary ... and library modules (with embedded dictionary to avoid springboarding) in their own High RAM segment, with the module call primitive handling the selection of the correct High RAM segment.
So just like the C64, the library modules would not be an option in the X8, and the dictionary would just build down from the end of regular RAM (as the alpha version of the CX16 xForth does right now), but hopefully it would be possible to have a couple of 8K block segments stored in video RAM. Copying four pages to and from the 1K Block Buffers a page at a time seems like it would be straightforward enough.
(new title): Hard decision, but the answer is pretty clear.
2 hours ago, x16tial said:
Of course they aren't. And I already said that assumptions are being made. But that could be easily remedied. By giving us access to all of the info and the emulator. This isn't being done and is the source of my frustration.
I've said it before and am saying it again: Give them a break. Also, you are starting to sound somewhat entitled, which probably isn't your intention.
Quote
This board might be less trafficked than the facebook group, but I'd argue the stronger supporters are here, where else is there software being released for the platform? Of which, myself, I've released some and have more in the works.
Careful hint ? : You may be, just maybe, overestimating the value of your so far released X16 software. ?
Quote
I immensely appreciate what the team has done so far. But we're ready, willing and able to pony up real cash for this/these products.
We're being asked if we want one of the said products, but we're being denied access to most of the information about it.
David is currently dealing with a major shakeup of his project. He's asked a question 5 days ago to feel the water about the option of an X8, and could probably spend some significant portion of his time just reading and digesting all the replies he's getting here in the forum, plus keeping an eye on all the other discussions, such as this one. He has given us an overview of the X8's specs, and I'm not surprised at all if he didn't have the time yet to reply to all the questions that came up.
It shouldn't be all that hard for all of us to muster the patience that is called for at the moment.
Quote
How is that not frustrating?
See above - let's be more considerate of all the other things on the project owners' table at the moment. And keep in mind - they have day jobs, too. This here isn't really it, not even for David, IIUC.
-
Carl Gundel
- Posts: 18
- Joined: Fri Aug 20, 2021 6:55 pm
(new title): Hard decision, but the answer is pretty clear.
On 8/22/2021 at 4:57 PM, Scott Robison said:
Agreed on IEC. It is nice from a nostalgia perspective, but it's not like the fast loaders that depend on 1541 are going to work on X16. The best reason I can see for IEC is not disk drives, but perhaps printers if anyone has those they want to use.
It's a serial port, right? Could be used for lots of things.