Maxi-/Uber-Edit

[Mike]

do you have a s[ol]ution for this question from Mike?
Is it possible to move the screen to $0400?

Torsten sent me that customized version a long time ago. This version however only works on real hardware when the +3K RAM are fitted internally, like in the VFLI mod - and that's specifically the reason I asked for it. The VFLI mod is emulated in VICE, you should consider though that if you go and program anything that requires the mod, the result will have a very small audience.

And how can I physically imagine the extension I/O-2 RAM ($9800-$9BFF)?
How does the I/O-3 RAM ($9C00-$FBFF) expansion work?

VICE then behaves as if RAM was present in addresses $9800..$9BFF (I/O2) or $9C00..$9FFF (I/O3). Nothing special about that.

Isn't that where the Basic and Kernal are located? See Mastering the VIC from A.J.Jones et alia on page 45.

I fetched that book from DLH/Bombjack and on page 45 nothing is mentioned about the locations of BASIC and KERNAL.

That info in turn is referenced in Appendix M on page 173, which mostly gets the facts right, except for the following detail: BASIC is (mostly) located in $C000..$E4FF, the KERNAL resides in the following address range, $E500..$FFFF. That means, BASIC is more like 9 KB in size and the KERNAL is 7 KB, so part of the BASIC interpreter actually sits in the so-called KERNAL-ROM.

It can be disputed, whether the reverse ordering of the addresses on pages 173/174 is pedagogically valuable.

[MrSterlingBS]

I mean this page from the book.
I always wondering about the free RAM space.

It was just for information.

[Mike]

Ah. That's the other "Mastering the VIC".

In the diagram, "Expansion ROM/non-existent" (a.k.a. BLK5) at "AC00" is in error and should be A000 instead.

Other than that, "Expansion? I/O non-existent" lumps I/O2 and I/O3 together at $9800..$9FFF.

It is somewhat unfortunate to label these areas simply as "non-existent". Whether they are present for the CPU or not crucially depends on what cartridge is plugged in. Circuitry on the cartridge will then map in RAM, ROM or I/O registers as intended.

Normally, the memory expansion areas in $2000..$7FFF and $A000..$BFFF can be "filled" with either RAM or ROM, $0400..$0FFF almost always is filled with RAM only. I/O registers of peripheral chips are supposed to go into the I/O range, i.e. $9800..$9FFF. It is however also possible to place RAM or ROM there (like I did with MINIMON) but the hardware timing is slightly different and this needs to be taken into account by the cartridge designer.

As I have written in another thread, the I/O range is a strict cartridge resource. 3rd party programs have no way to find out what's "there" (RAM?) without possibly triggering unwanted side-effects, if what actually *is* there is not RAM.

[MrSterlingBS]

Good morning,

is it possible to use Maxi-/Uber-Edit and MINIGRAFIK together?
With the two programs from DENIAL, not.

This would be extremely useful for an application I'm currently writing.

Best regards
Sven

[MrSterlingBS]

Another little thought...

Can the Maxi-/UberEdit be patched into the BASIC ROM?

[Mike]

is it possible to use Maxi-/Uber-Edit and MINIGRAFIK together?

It should very well be possible to run these two tools together. Maxi-/Uber-Edit and MG do not collide in their use of vectors: tokra's screen editor replacements wedge into the KERNAL I/O vectors, whereas MG hooks into the vectors of the BASIC interpreter.

With the two programs from DENIAL, not.

First of all, both tools (need to) change the BASIC start. Their BASIC stubs will not work from a changed BASIC start. To get both tools running together, you need to identify their memory allocation when they are installed and provide an own BASIC stub plus machine code that:

• protects BASIC memory,
• puts both machine code parts to their place, and
• initializes all involved vectors as necessary.

It should go without saying that the tools should not overlap their program code. It is more easier though to relocate the screen editor code than MINIGRAFIK: MG is located right behind the bitmap - first, to maximize available BASIC memory and second, there is a buffer in-between that holds compressed colour RAM data and the display code that goes with each file - so MG has to stay put.

This would be extremely useful for an application I'm currently writing.

This may well be. If your application involves providing more text on screen for a running program, there are also the 40 column text display routines available that come with MG BROWSE. These routines do not come packed with a corresponding screen editor though, as I did not see any need for it.

...

Can [...] Maxi-/UberEdit be patched into the [...] ROM?

Please check my earlier posts in this thread here to see why this is a bad idea.