Jump to content

Photo

E: editor and S: screen handler width


15 replies to this topic

#1 foft ONLINE  

foft

    Dragonstomper

  • 643 posts
  • Location:Nyon, Switzerland

Posted Thu Nov 16, 2017 3:54 PM

Is there a register for the width of the text window and graphics lines? I guess it exists for plot and drawto to work but cannot find it in mapping the atari!

e.g. Can I do something like this?:
gr.0
poke 559,33
poke ewidth,32

I ask because I'm wondering how to the integrate 2x and 4x colour clock modes on the EclaireXL. Of course a custom display list can be used but it would be nice if basic, dos and other XEP80 friendly software worked. Not to mention if I could do this it would be great:
poke 559,98 (gr.8 4x)
poke ewidth,160
poke gwidth,1280
color 1
plot 0,0
drawto 1279,100

I guess the 4k boundary issue would be a problem for the latter example, but ignoring that ... are there some simple pokes i can do to the editor and screen handlers to get close?

#2 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,263 posts
  • Location:Australia

Posted Thu Nov 16, 2017 4:53 PM

No.  The only width control is LMARGN/RMARGN which is referred to for Graphics 0.

 

Though a bit wasteful there's a couple of workarounds to get the OS to be able to do meaningful work if you're in narrow DMA mode.

You could use a custom DList with LMS on every line to force 40 byte alignment instead of 32.

 

Or you could enable HScrolling which with the extra memory demand brings it to the same as normal mode.  You could use a HSCROL value of $0F which means you have the first colour-clock worth of pixels not visible but then an otherwise normal screen.  Or just figure the missing pixels in your calculations and don't use them.



#3 foft ONLINE  

foft

    Dragonstomper

  • Topic Starter
  • 643 posts
  • Location:Nyon, Switzerland

Posted Fri Nov 17, 2017 1:48 AM

Thanks. I guess Ill need to understand and patch S: and E: then.

#4 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,263 posts
  • Location:Australia

Posted Fri Nov 17, 2017 3:20 AM

A lot of it's table based.  Problem is there's 4 bits only used for graphics mode which on XL OS is all used (remembering 800 only went to 11).

There's lookup tables for how much to add per scanline, X/Y boundaries etc.

I think in theory given the 320 modes already have 2 bytes for XPos, a 640 or 1280 mode would probably incorporate fairly easily if that's what you were after.  But the YPos is only one byte wide.



#5 foft ONLINE  

foft

    Dragonstomper

  • Topic Starter
  • 643 posts
  • Location:Nyon, Switzerland

Posted Fri Nov 17, 2017 3:26 AM

Thanks. I guess I can put the os in ram then poke that table dynamically to start with. Or find a few bytes to check width and left shift the width.

I dont need larger ypos yet since its still the same hsync just faster pixel clock. Though that could be an interesting future step.

Edited by foft, Fri Nov 17, 2017 3:32 AM.


#6 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,263 posts
  • Location:Australia

Posted Fri Nov 17, 2017 9:18 AM

I'd suggest do interlace support, which would be 480 pixels height.  Though doing the display lists and other stuff would add a whole layer of complexity.



#7 foft ONLINE  

foft

    Dragonstomper

  • Topic Starter
  • 643 posts
  • Location:Nyon, Switzerland

Posted Sat Nov 18, 2017 11:14 AM

These tables get a fair way. So far I've set the left shift to 4 instead of 3 (EE6D) and then the ctrl keys work. + Listing programs gives me the expected 1/line.

 

Then I tried line length using 0x50 instead of 0x28 in EE7D. That isn't working so well. Also poke 83,79 isn't 'sticking', something chops it back to 39. Anyway quite interesting to see the graphics mode table based structure, will continue to play...



#8 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,263 posts
  • Location:Australia

Posted Sat Nov 18, 2017 8:52 PM

Pretty sure there's a compare/set for the margins to keep them sensible.

Another possible showstopper is the logical line mapping.  Not sure how that'd cope e.g. on 80 columns though 3 lines gives 240 which keeps it in 8 bits, and languages tend to set a 256 byte input buffer anyway to allow for expanded records coming in from LISTed files.



#9 foft ONLINE  

foft

    Dragonstomper

  • Topic Starter
  • 643 posts
  • Location:Nyon, Switzerland

Posted Sun Nov 19, 2017 2:44 PM

Yeah its checking the right margin in F6CA... Unfortunately not a common location for width but an A9 XX. I see a whole bunch of 0x27 and 0x28's in the code around here and through the scrolling routines beyond... I guess I can change them all and see if it works!

 

S: on the other hand is looking not so bad. I can plot and drawto the full width in Gr.0 just fine. Not tried the other modes yet. 



#10 foft ONLINE  

foft

    Dragonstomper

  • Topic Starter
  • 643 posts
  • Location:Nyon, Switzerland

Posted Sun Nov 19, 2017 2:49 PM

Does anyone have a routine handy to recalc the checksum? I'm adjusting a byte down for each one I increment right now in a hex editor and its a bit annoying! I've also not found a handy routine to put the OS in RAM, of which I'm sure there are a lot! So I can test with poking. Does anyone have one handy please?



#11 HiassofT ONLINE  

HiassofT

    Stargunner

  • 1,041 posts
  • Location:Salzburg, Austria

Posted Sun Nov 19, 2017 3:53 PM

Does anyone have a routine handy to recalc the checksum? I'm adjusting a byte down for each one I increment right now in a hex editor and its a bit annoying! I've also not found a handy routine to put the OS in RAM, of which I'm sure there are a lot! So I can test with poking. Does anyone have one handy please?

Download my highspeed SIO patch and have a look at romram.src and hipatch.src. The latter contains code to update the ROM checksums.

so long,

Hias

#12 foft ONLINE  

foft

    Dragonstomper

  • Topic Starter
  • 643 posts
  • Location:Nyon, Switzerland

Posted Mon Nov 20, 2017 2:41 PM

Thanks. Much easier to create a patched rom with this Hias. Modifying patchrom.cpp...

Problem of the day... screen memory allocate is only one byte and is in units of 40 bytes. At least I think it is! Perhaps another 0x28 to change somewhere.

I should probably grab the screen handler asm and reassemble it then plug it in here to patch this. Then I can modify the code properly to detect the width etc.

#13 foft ONLINE  

foft

    Dragonstomper

  • Topic Starter
  • 643 posts
  • Location:Nyon, Switzerland

Posted Mon Nov 20, 2017 3:27 PM

I change a bunch of the 0x27 and 0x28's to the same + 0x28 (avoiding the php's!). After this gr.0 is working pretty well. I can move the cursor around the full screen and generally it seems happy. Until I scroll when it crashes in a heap, Ho hum. 

 

As a proof of concept I'm pretty pleased, doesn't look like there will be _too_ many changes to make this work properly in all modes.

 

Forgot one thing, the buzzer sounds after 1 line and a half - which I guess is good for the 256 byte input buffer thing?


Edited by foft, Mon Nov 20, 2017 3:27 PM.


#14 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,263 posts
  • Location:Australia

Posted Mon Nov 20, 2017 6:54 PM

E: keeps track of the cursor "logical column" position which can be from 0-119 (it ignores margin settings in the calculation).  LOGCOL location $63.

Likely there's a compare somewhere, the buzzer sounds when it hits value $71, it seems to use that value regardless of what you set the margins to.

 

Possibly you'll need to hunt some stuff out in E: to get 160 or 240 character logical lines working properly.



#15 thorfdbg OFFLINE  

thorfdbg

    Dragonstomper

  • 746 posts

Posted Thu Dec 7, 2017 7:38 AM

Problem of the day... screen memory allocate is only one byte and is in units of 40 bytes. At least I think it is! Perhaps another 0x28 to change somewhere.

I should probably grab the screen handler asm and reassemble it then plug it in here to patch this. Then I can modify the code properly to detect the width etc.

It's more complicated than that. There is a cursor address computation function in the Os  (ComputeCursorAddress  in Os++, in the file screen.asm), but separate asumptions about the line width in the editor for scrolling, and logical line length computation. If you want to check, Os++ sources are free to download, and come with a Makefile that also compute the checksum along its way.



#16 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,802 posts
  • Location:United Kingdom

Posted Thu Dec 7, 2017 8:06 AM

I was about to suggest Altirra OS as a good starting point, since there's plenty of free space left in the ROM.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users