4k RAM under i/o $D000 to $Dfff

[Whammo]

A nice chunk of memory just lying fallow. It is a bit of trouble to use.
There is no memory configuration where it is accessible, and the Kernal at the same time.
It would require placing interrupt vectors in RAM underneath the Kernal, six bytes at the end of memory.
Although RAM under the Kernal is reserved for the hires screen.
I'm thinking $d000 $DFFF might be a good place for the dictionary.
Some fiddling with the interrupts. and I think it is doable.

Ed. Just disable IRQ.

[Whammo]

Since bmpbase only goes up to $E3E8, it seems there's room up there for the vectors, and perhaps the necessary amount of code required.
Only interrupts that occur during access to $D000 - will be affected, otherwise the Kernal will be in context.
One trick, on interrupt, before you push the registers, save A to a safe place, bank i/o back in, and push the appropriate return address and status to a routine that ends with RTI, to bank i/o and Kernal back out when it's done, restore A and JMP thru the Kernal vector,
RTI of the IRQ routine calls your routine, whose RTI returns you to accessing the dictionary.

Ed. Just sad...

[Whammo]

This could also be accomplished perhaps more simply by masking IRQ's while accessing dictionary under i/o, and only dealing with NMI's. Indeed a simpler prospect!

[Whammo]

Is 4k suitable as a hard limit for dictionary size? Don't want overflow into hi-res graphics colors.

Ed. non-issue

It seems the safest and simplest way to access data in the RAM under I/O is under IRQ.

Ed. perhaps...

Actually executing code there is a bit more.

Ed. not in the plan

[jkotlinski]

I'm not sure if 4K is a good hard limit. However, there is nothing that would prevent the dictionary from starting at $dfff and then grow downwards into $c000 area.

I foresee a practical problem, but it might be possible to work around:
How to load and save the dictionary if it's in the $d000 area?

[Whammo]

Use between HERE and bufstart as an intermediate buffer to save/load from/to $d000, MOVE is really fast!
I'm not saying it won't be tricky, or have diminishing returns, but contiguous memory is pretty cool.

[Whammo]

Also, the idea isn't a 4k hard limit, but 910 word hard limit, as strings would be at $9fff - latest
Having everything in arrays makes sorting entries easy. There are always trade-offs.

[burnsauce]

Dictionary movement is already implemented with TOP!

[Whammo]

That's what gave me the idea.

[Whammo]

So, I was watching this guy: https://www.youtube.com/watch?v=xoyDNIcnpgc&t=9051s
He was saying he liked to split his dictionary up into arrays, so that he could search them with a machine instruction.
Would a hard limit of say, 910 words be generous?

Three arrays, RAM under I/O

455 bytes as nibbles for 910 attributes
1820 bytes as 910 words for execution tokens, and
1820 bytes as 910 words for string addresses
4095 bytes total under I/O,
strings at $9fff

[Whammo]

There are many interesting implications to storing the components of dictionary entries in separate arrays.
Search becomes faster, sorting, re-arranging, optimizing order...
Transitory words, load, compile execute, forget.

[Whammo]

Words with the transitory attribute bit set, will return memory amount requested from the execution token array

[burnsauce]

If you want to put together a design document for a new dictionary, maybe start compiling it in a gist.

[Whammo]

My first shot at the NMI stub would be:

: stub-nmi $fffc $fffa ! $40 ( rti ) $fffc c! ;

[Whammo]

In a wild dream one might think that it would be as simple as:
if STATE = 0 then io-io ; executing
if STATE <> 0 then ram-io ; compiling

[burnsauce]

Other words beside compiling words use the dictionary. You should check out wordlist.fs for instance. Likely the low-level dictionary functions themselves would need to be wrapped with the bank swap.

[Whammo]

It looks like it's,
io-io then REFILL
and
ram-io then EVALUATE

[Whammo]

Whether it's interpreting or compiling RAM is in context. When it's filling the input buffer, i/o in in context.

[Whammo]

I reckon it starts interpreting what's in the buffer when it receives a CR.
So,
It must be REFILL. I'm looking real hard there.

[Whammo]

Could it be so simple?
Whoops- execute wants i/o in context so,

interpret_loop

    jsr io-io
    jsr REFILL

    jsr ram-io
    jsr interpret_tib
    
jmp interpret_loop

........

EXECUTE
    jsr io-io  ; would have been fun though!
    lda LSB, x
    sta W
    lda MSB, x
    sta W + 1
    inx
    jmp (W)

[burnsauce]

Compile it and let me know! :)

A good test would be $dfff TOP!

[Whammo]

You think I can compile this stuff from source?
What do you think, I'm some kind of nerd or something?

😃

[Whammo]

.on_stack_underflow and .on_data_underflow

will cause chaos if io is out of context
These types of issues can probably be fixed by:

PUTCHR
     pha
     jsr io-io
     pla
  ;  jsr chrout    <-------- OMG! Did I just do this?
  ;  rts
     jmp chrout   <---------Better!
                  

Loading PUTCHR in this manner, would only be for swapping i/o in on errors, would use CHROUT outside of the interpreter loop.
Except perhaps for immediate words .( like this)
PUTCHR state-smart word? We're already using PUTCHR interchangeably with CHROUT.
Could this be an actual or a long-forgotten mechanism?

   +BACKLINK "page", 4
PAGE
    lda #K_CLRSCR
    jmp PUTCHR

    +BACKLINK "rvs", 3
RVS ; ( -- ) invert text output
    lda #$12
    jmp CHROUT

[burnsauce]

What do you think of this alternate approach to using this space?

[Whammo]

It could be a nice little 4k REU with store and fetch and swap. It could be extended to use ram under kernal too.

[burnsauce]

By making the i/o space user-accessible but optional, there would be no code space or complication added to the base distribution. Leave it on disk so users who need it can include it and use it.

Maybe there's something similar in the standard...

[Whammo]

Still you have to admit that seeing a big 'ol empty space in between HERE and $cfff would be mega, super, ultra, uber cool.

[Whammo]

Perhaps the best use for all that RAM under the Kernal is to fastload whole files to RAM and evaluate them rather than reading each line off the drive, byte-by-byte and interpreting.
Then again, this might be a good mechanism for this 'transitory words' thing I was grunting about.
Or not...

[Whammo]

The dictionary will be fine if it goes over 4k. Arrays are down the road, if ever.
Compiling and interpreting will be slightly faster with no IRQs

I should be able to pull this off without adding another page of memory...

!set WORDLIST_BASE = $dfff

[Whammo]

One small issue: DUMP ing ram under i/o. But this is the same issue as ram under Kernal. Still, easy to solve, and fun doing it.

[pzembrod]

I may be able to add some perspective and experience to this thread, from the "large" C16 version of the C64 flavour of VolksForth](https://github.com/forth-ev/VolksForth/tree/master/6502/C64) which I maintain.

The "large" in the C16 version means large memory. It makes the full range from $1001 to $FD00 available for Forth, with the Kernal and Basic ROM ($8000-$FFFF) being switched off. They are only switched on, via a bank-switching-wrapped JSR, for Kernal calls (typically I/O), and the same is done for IRQ where the vector in RAM points to a bank-switching IRQ handler which switches on the ROM, calls the IRQ handler there, and then switches back to RAM.

In essence, the default state is all RAM, and only for Kernal calls is the ROM switched on. I haven't created a similar C64 version yet because it wasn't needed yet (the C16 without this scheme would only have RAM from $1001 to $8000), but since this works flawlessly on the C16, I don't see why it shouldn't work on the C64, too, and probably for DurexForth just as well as for VolksForth.

[Whammo]

Thanks for the input, and introducing a term that should have used with the proposed handling of PUTCHR, rather than state-smart, is jsr-wrapped.
When the kernal is In context, use CHROUT, otherwise, PUTCHR.

[jkotlinski]

There is some precedent in using memory in "odd" addresses, as you are aware, this is done for bitmap graphics too (the bitmap is placed under Kernal ROM)

For graphics, it's not so bad, because the bank switching only needs to be done in a few places.

For the dictionary, I suspect there is a good number more words that would need to bank switch, but I am not 100% sure.

[Whammo]

Even if this scheme turns out to be non-viable, I will have interpreter and compiler under my belt by the time it's figured out.

[lonetech]

Solution looking for a problem mode here! Several core operations could be converted to lookup tables.

CHAR_TO_LOWERCASE - called once per character in HEADER, FIND_NAME and READ_NUMBER. That includes every interpreted word. Current size: 28 bytes, runtime: 12+2=14 or 12+10+2=24 cycles, not counting the return. Replacement cost: 3 fills for setup, then one table lookup. Table size: 256 bytes.

READ_NUMBER core loop - not only calls CHAR_TO_LOWERCASE, it then does the digit translation. This could also be put in a table. Setup cost: one fill, two sequential writes (the lowercase table could be folded in). Table size: 256 or 128 bytes.

Name lookup: The hash table I prototyped in #428 could be applied. Perhaps even once per word-list, if we implement search-order. Table size: preferably 512 bytes, could be smaller (initial test used 256).

Cost of a table lookup into the $d000 memory: Mapping that RAM, as kernal-in/out twice, 2*6 cycles, 10 bytes. Cost of a lookup: 3 bytes, 4 cycles, not counting the work to put the entry into X or Y.

To have an advantage we'd need to move the mapping step outside of the loops. Of course, we could start simpler and use main RAM to see how much a performance gain we'd get.

I think the rational next step is a profiler in Vice, to measure where the most time is actually spent during compilation.

PS: An initial test of a table based lowercase routine showed no appreciable difference in the time to compile v, so the profiling is needed.

[Whammo]

How about a word noirq , a value, noirq-here that swaps with here when noirq is executed during compilation.
words under noirq would be compiled to and execute from $d000- and reenable irq at ;