Jump to content
  • 0

How to make BSOUT or CHROUT to write to vera layer 0 (text) instead of layer 1


svenvandevelde
 Share

Question

The default text layer used by the kernal is vera layer 1.

How is it possible to redirect the CHROUT/BSOUT kernal routines (FFD2) to write to vera layer 0 (yes, i've copied the PETSCII charset to another place).
Does anyone know how to do that, or is such not possible?
Since the ROM has all the required kernal routines for character output to the screen, i thought such a feature would also be included, but I cannot find it :-(.
Is the vera layer hardcoded in the ROM???

note: I understand very well how to write using the vera registers directly. Is using vera directly an option?
(does the kernal "understand" which layer is configured on the vera for text mode?)

Sven

Edited by svenvandevelde
Link to comment
Share on other sites

10 answers to this question

Recommended Posts

  • 0
Posted (edited)

Never mind ... Michael has been hardcoding this stuff in the ROM ...

x16-rom/screen.s at master · commanderx16/x16-rom · GitHub

He did not use the "mapbas" variable to offset the cursor position calculation using ptr...

image.png.caf8947ed4c7e45de17d11f0352155d4.png

 

image.png.cd6ad5565322201dd8833923305147f3.png

 

If you would give the ROM to me I would make this more flexible!

1. Add an API in the kernal to offset the mapbase in the vera for basic screen functions (bank+offset).

2. Add an API in the kernal to set the active layer.

3. Add an API to switch cursor blinking on and off.

 

I mean, the CX16 has a FIXED ROM that cannot be switched off. What use is a fixed rom if for more advanced and fancy programming it cannot be either:

- used:

- switched off to get more RAM and be replaced by customer ROMs (in RAM)

 

...

Edited by svenvandevelde
Link to comment
Share on other sites

  • 0
On 3/27/2022 at 5:41 AM, svenvandevelde said:

I mean, the CX16 has a FIXED ROM that cannot be switched off. What use is a fixed rom if for more advanced and fancy programming it cannot be either:

It's not uncommon for kernal ROM to make assumptions about resources being in fixed locations.

While the kernal ROM can't be replaced by RAM, it does support many extra ROM banks to do different things.

Link to comment
Share on other sites

  • 0
On 3/27/2022 at 6:04 PM, Scott Robison said:

It's not uncommon for kernal ROM to make assumptions about resources being in fixed locations.

While the kernal ROM can't be replaced by RAM, it does support many extra ROM banks to do different things.

I'll see if the R38 ROM can be adapted on github and I'll do a pull request. 

Link to comment
Share on other sites

  • 0
On 3/27/2022 at 3:08 AM, svenvandevelde said:

The default text layer used by the kernal is vera layer 1.

How is it possible to redirect the CHROUT/BSOUT kernal routines (FFD2) to write to vera layer 0 (yes, i've copied the PETSCII charset to another place).
Does anyone know how to do that, or is such not possible?
Since the ROM has all the required kernal routines for character output to the screen, i thought such a feature would also be included, but I cannot find it :-(.
Is the vera layer hardcoded in the ROM???

note: I understand very well how to write using the vera registers directly. Is using vera directly an option?
(does the kernal "understand" which layer is configured on the vera for text mode?)

Sven

You might find it easier to just set the VERA address pointer and just push data straight to VERA 

  • Like 1
Link to comment
Share on other sites

  • 0
On 3/28/2022 at 12:31 AM, Ed Minchau said:

You might find it easier to just set the VERA address pointer and just push data straight to VERA 

That is not an option if you want the program to "echo" your outputs to the terminal console in the emulator for debugging purposes. I'm using vera registers all the time as I've written earlier. 

I'm developing a game engine with multiple in memory objects like a memory manager, sprite movement and event engine, tile scrolling engine, collision detection using a spacial grid hashing table, ...

I need some kind of debug log in the terminal during execution, as a lot is going on. Yesterday I spent the whole day identifying the root causes of memory being overwritten during execution. So it would be good I can log data using a kernal call CHROUT so it gets echoed in the terminal emulator. ( -echo option ).

The issue is that CHROUT writes to the screen on the vera in bank $0 starting from offset $0000. The default screen is 80x60 characters. When the vera base registers have been remapped for other purposes, writing text on the screen using kernal call CHROUT might overwrite the new vera data (like new tiles) at the default $00:$0000 vera base map. 

And I've identified a workaround which is not perfect but works...

The debug output to be generated at lowest level is character per character, so I first do a PLOT kernal call to coordinate 0,0 and then I do a CHROUT kernal call to print one character at the top left corner of the screen. This pollutes my (remapped) vera data with one byte but that is a small sacrifice for the debug benefits I get. 

And this is done for all the debug text. 

I don't know how else I can generate debug output at this moment. Don't want to use files because it is slow and consumes a lot of memory and it's not really accessible. 

What would be nice is some sort of "debug" api feature that can trace outputs. 

Link to comment
Share on other sites

  • 0
Posted (edited)
On 3/28/2022 at 5:00 PM, Ender said:

When I'm debugging I usually just use the debugger that you can get to with F12.  I usually find it more useful to interactively debug things than to look at a log afterwards.

The F12 debugger is not showing any labels. I find it extremely hard to use. Not sure if you have the same experience. And also, it is very hard to debug on a running scenario in the middle of raster scan interrupt handling. I use the technique also but find debug lines and then recompile, re-run the most efficient; the other thing i do is to display info on the layer 1 while the background tiles are on layer 0. But this i won't be able to do anymore once i have the parallax layer active.

 

Edited by svenvandevelde
Link to comment
Share on other sites

  • 0
On 3/28/2022 at 11:22 AM, svenvandevelde said:

The F12 debugger is not showing any labels. I find it extremely hard to use. Not sure if you have the same experience. And also, it is very hard to debug on a running scenario in the middle of raster scan interrupt handling. I use the technique also but find debug lines and then recompile, re-run the most efficient; the other thing i do is to display info on the layer 1 while the background tiles are on layer 0. But this i won't be able to do anymore once i have the parallax layer active.

 

It's true, the current debugger doesn't show labels, which is a bit of a hassle.  I think a pull request was made at one point that completely revamps the debugger and allows you to load a symbol file that adds them, but it hasn't been accepted yet.  Usually I just look at a symbol file to see the address for the labels and go by that (if you're using ca65 you can create one by compiling with "-Ln file.sym").  I just think the F12 debugger might be useful for you because you can see VRAM as you're debugging with the v command, ("v <address>" and then scroll up/down with pgup/pgdn).

Link to comment
Share on other sites

  • 0
On 3/28/2022 at 6:42 AM, svenvandevelde said:

I need some kind of debug log in the terminal during execution, as a lot is going on. Yesterday I spent the whole day identifying the root causes of memory being overwritten during execution. So it would be good I can log data using a kernal call CHROUT so it gets echoed in the terminal emulator. ( -echo option ).

The issue is that CHROUT writes to the screen on the vera in bank $0 starting from offset $0000. The default screen is 80x60 characters. When the vera base registers have been remapped for other purposes, writing text on the screen using kernal call CHROUT might overwrite the new vera data (like new tiles) at the default $00:$0000 vera base map. 

And I've identified a workaround which is not perfect but works...

The debug output to be generated at lowest level is character per character, so I first do a PLOT kernal call to coordinate 0,0 and then I do a CHROUT kernal call to print one character at the top left corner of the screen. This pollutes my (remapped) vera data with one byte but that is a small sacrifice for the debug benefits I get. 

And this is done for all the debug text. 

I don't know how else I can generate debug output at this moment. Don't want to use files because it is slow and consumes a lot of memory and it's not really accessible. 

You can redirect the CHROUT forwarding vector at $0326 to a CLC and RTS, so a call to CHROUT will return immediately with a carry clear (success indication). Fast and no impact on VERA.

MON
...
.A1000 18 CLC
.A1001 60 RTS
M0326
.:0326 00 10 ...

The emulator -echo option will still trap the call to $ffd2 and log the character to the host terminal.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use