My First C64/X16 Programs!

[SerErris]

27 minutes ago, SlithyMatt said:

I don't think any one program would need all of these, unless it was a scientific calculator or really advanced spreadsheet. If you need to do one or two of these calculations very often, it would be totally worthwhile to take up the space in banked RAM.

Sure, but even if you take the smallest of the tables above, it is 64kb ... so several banks (actually 8 ). And each lookup need to lookup first the bank, than switch the bank and then lookup the value. Yes it is possible, but also slower than expected. Larger banks will even increase.

12 minutes ago, geek504 said:

I was thinking to use an external card using Memory Map I/O akin to VERA chip with its own memory banks, i.e. the external 2MB RAM accessible by the 32 bytes I/O memory. The X16's RAM would be preserved.

 

Using the SD card ... not sure how long you have to wait for a single load and also not sure how that even shall work. The SD card will most likely still emulate a IOdevice. But maybe I am wrong. Even if you can access the SD card on block level you need to setup the VERA registers, calculate what block you need, load the full block somewhere and then select the Value inside of the block. So most likely that is also not a good in the meaning of fast lookup procedure. It might be even slower than calculating it. Maybe someone has a good idea how that could be implemented, but I cannot see a fast way. Of cause we do not know how access through VERA to SD card will work.

 

[geek504]

14 minutes ago, SerErris said:

Using the SD card ... not sure how long you have to wait for a single load and also not sure how that even shall work.

Not using SD card nor using VERA. Another independent circuit inserted into one of X16's slots as per spec below:

Expansion

• 
  Four expansion slots with access to CPU databus
  


• 
  Each slot has its own 32-bytes of mapped RAM
  


• 
  8 general-purpose I/O lines available (user port)
  

[SerErris]

Ah ... got it. That might potentially work, but will be quite expensive. You need a card, and all of that and then the SD card itself (which will be minor cost obviously compared to the rest). But yes - might work.

[geek504]

7 minutes ago, SerErris said:

Ah ... got it. That might potentially work, but will be quite expensive. You need a card, and all of that and then the SD card itself (which will be minor cost obviously compared to the rest). But yes - might work.

what's wrong with the good old ROM chips? Actually EEPROMs would be better.

[rje]

Thanks for posting the tables, Mr. Geek 504.  It is a Big Gulp for sure, but it's always nice to discuss options, be it ROM or a card or whatever.  Wolf3D on the X16.... whoo....

 

Did you say you were new to the Commodore Line of Stuff?  You do know about the KERNAL though, right?  And the X16's pseudo-16-bit routines?  And Bruce's variant of SWEET16?

 

[geek504]

5 minutes ago, rje said:

Thanks for posting the tables, Mr. Geek 504.  It is a Big Gulp for sure, but it's always nice to discuss options, be it ROM or a card or whatever.  Wolf3D on the X16.... whoo....



 



Did you say you were new to the Commodore Line of Stuff?  You do know about the KERNAL though, right?  And the X16's pseudo-16-bit routines?  And Bruce's variant of SWEET16?



 

Yeah, I grew up on the other side, the dark side known as Apple ][. The only Commodore I owned was an Amiga500. I'm not familiar with the term KERNAL but I assume it to be all the built-in ROM functions for all sort of stuff needed by the computer (e.g. input, output, clear screen, parser, commands, graphics, etc.) and accessible by the programmer using SYS (Apple ][ is CALL) and JSR (in assembly). I'm also assuming that X16 new commands were implemented in ROM as well using 6502 assembly. But when you say "pseudo", I'm not sure now. An 16-bit routines? I am aware of Steve Wozniak's SWEET16 implementation for the Apple ][ Integer ROM but that wasn't used much and didn't include math functions, just simple 16-bit LDA and STA. Why does X16 need a SWEET16 implementation?

I have studied the entire Apple ROM disassembly... have yet to do the same with C64 when time is available. What I find the most peculiar and impressive is how C64 handles graphics and sprites with layers! That is amazing for an Apple ][ guy. I just watched yesterday The 8-Bit Guy's video on "Oldschool Graphics" and C64's use of COLOR CELLS versus Apple ]['s NTSC ARTIFACT COLORING.

The most impressive of all is using the C64's CPU to change the color palette on each scanline of each color cell and achieve amazing pictures! (it's in Part 2 at 5:00)

[rje]

I admit the things people did/do with the C64 is Scary Magic, and I'm not worthy.

Yes, the KERNAL is the jump table common to all 8-bit Commodore computers for handling I/O (mostly?).  It's a Good Thing.

The X16 doesn't have a SWEET 16, although Bruce has created a variant of it "for fun" somewhere around here.

However, the X16 does have new routines for handling 16 bit values, stored in pseudo-registers in zero page.  It's not a VM, but simply a set of convenience routines.  Michael is to blame for them, at least partly, and I think they're a Good Thing too.

 

[geek504]

19 minutes ago, rje said:

Yes, the KERNAL is the jump table common to all 8-bit Commodore computers for handling I/O (mostly?).  It's a Good Thing.

Ah, the KERNAL is a JUMP TABLE! The Macintosh 128K et al. has the same feature... allowing ROM bugs to be fixed in RAM and simply changing the value in the JUMP TABLE. It is a GOOD THING! Especially because I read the following:

Quote

All Commodore BASICs, except BASIC 7.0 for the Commodore 128, have a bug in the multiply routine which can produce incorrect results for some pairs of operands.

Someone might actually want to fix that in the ROM itself...

[rje]

Okay, I was misleading.  The KERNAL routines developed a bit up until the VIC-20, but there still is compatibility, and the intent was to provide a separation -- an API -- between the system and MS BASIC.  By the time of the VIC-20, the KERNAL was documented and forward-compatible.

Your (fun!) reading assignment:

https://www.pagetable.com/?p=926

And the (even funner!) KERNAL API reference:

https://www.pagetable.com/?p=1401

[SerErris]

18 hours ago, geek504 said:

Ah, the KERNAL is a JUMP TABLE! The Macintosh 128K et al. has the same feature... allowing ROM bugs to be fixed in RAM and simply changing the value in the JUMP TABLE. It is a GOOD THING! Especially because I read the following:



Someone might actually want to fix that in the ROM itself...

The KERAL is actually the all the functions sitting in the ROM required for the bare IO functions for the Commodore Computers to work. BASIC is another part which is interfacing with the KERNAL for more low level access..  It is not the jump table, but it has a jump table. The jump table is in ROM.. but obviously you could copy the jump table to anywhere, (a bank for instance) and change some parameters. However the Jump Table assumes, that you are and stay within the current selected banks. You cannot jump across banks with the KERNAL, as the KERNAL is not aware of banked RAM like the X16 has. It can only bank-in ROMs into the addressable space (e.g. CHARROM, KERNAL ROM, BASIC ROM) and as I said if you are inside the KERNAL, you can only jmp within the KERNAL - not into another ROM bank for instance...



That brings me to one question: KERNAL and BASIC live in different ROM banks. So how is it possible that BASIC calls a KERNAL function? What is happening to switch the BANK before the JSR ? The more I think of it, the more my head is spinning. So you would need to do a bank switch, and then the next instruction from the ROM you worked in is not available anymore.



Lets assume you have the BASIC ROM paged in (#4). You work in a routine and want to call CHROUT (for instance) from KERNAL. So you prepare the page for KERNAL ROM (#0) and then the next instruction executed is the on sitting in KERNEL ROM ad the address in PC instead of the instrcution in BASIC ROM. 

Any idea how that works in X16?