6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Apr 27, 2024 4:46 pm

All times are UTC




Post new topic Reply to topic  [ 38 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Fri Nov 06, 2020 10:23 pm 
Offline

Joined: Fri May 05, 2017 9:27 pm
Posts: 851

Although the character ROM can be switched into the memory map so it can be copied elsewhere and altered, it is normally not in the memory space seen by the processor. It is mapped to the same address as the system I/O.
The VIC II chip can see the character ROM even when the processor can't. Altering the character set would require increasing the size of my Forth kernel to have memory for a copy of the character set. I say 'at least' because the character map has to start on a certain address boundary.
I personally don't think it is worth making my kernel that much bigger just to support some custom characters. Characters that will not show up any different than the original on printed output.
In my case, the 'printed output' is the print dump file from VICE, the Commodore 64 simulator. If I want a listing of the Forth kernel source that can be read by something other than a Commodore 64, I just print the source and rename the print dump file.


Top
 Profile  
Reply with quote  
PostPosted: Mon Nov 09, 2020 8:51 pm 
Offline

Joined: Sun Nov 08, 2009 1:56 am
Posts: 387
Location: Minnesota
It's been a long time since I played with any of this, but if IRRC the RAM "underneath" the character ROM (seen by the VIC-II chip) and the I/O (seen by the 6510) on the C64 can be accessed by playing with the registers that control the memory map. It's possible to copy the character ROM into that RAM and point the VIC-II at it while the 6510 still "sees" I/O there. Once in RAM you can alter the character set any way you like. If you weren't already using that RAM for anything (and in the default configuration you're not), you haven't reduced your available memory.


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 10, 2020 1:17 am 
Offline

Joined: Fri May 05, 2017 9:27 pm
Posts: 851

That would be possible, but I don't think it would be practical just to add a custom character or even a few custom characters. After the new character set was created, the following would need to happen each time my Forth was loaded:
Load the Forth system.
Load the character set to a temporary location.
Disable interrupts and switch out I/O.
Copy character set to address $D000.
Switch I/O back in and re-enable interrupts.
Change VIC-II 'bank' to the top 16k. The VIC-II chip can only access 16k of memory. Which of the 4 16k 'banks' of memory it can access is set by bits 0 and 1 of port A of CIA#2.

Since my Forth has the command FSAVE to save a new copy of the Forth system, the following would need to happen each time a new Forth was saved:
Save the Forth system to disk.
Disable interrupts and switch out I/O.
Copy character set from $D000 to a temporary location.
Switch I/O back in and re-enable interrupts.
Save (or replace) the character set to disk.

There may be an easier way to do this. If there is, it still won't change what gets sent to the printer.

In summary, I just don't think it's worth the effort.


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 10, 2020 4:14 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1927
Location: Sacramento, CA, USA
There must be a PETSCII character that appears similar, like $A4 ... I'm pretty sure that PETTIL would allow it, and it would look fine on the CRT, but then you have the complementary issue of needing a PETSCII-capable printer for your hard copy. Back in the day I had an interface between my C=64 and my Epson MX-80 that did the conversion on-the-fly, but it was slow and a bit choppy.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Wed Nov 11, 2020 10:56 pm 
Offline

Joined: Fri May 05, 2017 9:27 pm
Posts: 851

Yeah, In my opinion, it's not really worth the effort.
Besides, can't anyone think of a better name than 2_PICK or 2-PICK or even 2PICK ?
We have the name DUP instead of 0_PICK and OVER instead of 1_PICK . Shouldn't there be a nice short easy to type name to copy the third stack item?

Speaking of PICK , The phrase n PICK could be interpreted as:
Not counting n, skip n items on the data stack and place a copy of the next item on the data stack.
I mention this because Mosaic defines a non standard word DPICK . This word skips n items and places a copy of the next two cells on the data stack. If the data stack had a double number with three single numbers on it like this:
Code:
D N1 N2 N3

the way to place a copy of the double on the top of the stack would be with the phrase:
Code:
3 DPICK

with the resulting stack effect:
Code:
D N1 N2 N3 D

I like this version of DPICK because if there is a double number that needs copied to the top and there are an odd number of single cell stack items, the double number can still be copied with ease.


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 06, 2023 5:53 pm 
Offline

Joined: Fri May 05, 2017 9:27 pm
Posts: 851

Ansi Forth has the word /STRING
Code:
/STRING  ( ADR1 U1 N1 -- ADR1+N1 U1-N1 )

I have use for a word with the following stack effect.
Code:
/MOVE  ( ADR1 ADR2 U1 N1 -- ADR1+N1 ADR2+N1 U1-N1 )

I have the code. I'm not so sure about the name slash move, /MOVE . Does anyone know of a standard name or a name in common use for this?


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 06, 2023 8:05 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
What's it for?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 06, 2023 8:33 pm 
Offline

Joined: Fri May 05, 2017 9:27 pm
Posts: 851

CMOVE>V to move data from C64 memory to virtual memory and CMOVEV> to move data from virtual memory to C64 memory.
Code:
: CMOVE>V  ( ADR VADR CNT -- )
: CMOVEV>  ( VADR ADR CNT -- )

Virtual memory is kept in blocks. The range of block numbers is usually for blocks residing in the C64's Ram Expansion Unit.
Each of these words move memory by calling CMOVE in a loop to move memory between C64 memory and a block buffer.

Some virtual memory words.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 38 posts ]  Go to page Previous  1, 2, 3

All times are UTC


Who is online

Users browsing this forum: No registered users and 15 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: