flashjazzcat Posted January 3, 2012 Share Posted January 3, 2012 Hmmm... it's an interesting problem. Programmatically, the most sensible time to upscale the font is when it's loaded from disk, but you then burn 100KB of VRAM. Upscaling on the fly introduces extra real-time processing and almost defeats the object of using the blitter to render fonts. I see little point in thinking too much about this when the standard GUI isn't even finished yet, but a solution will need to be found for this to ever come off. The thing about VBXE resources is they tend to be bigger by necessity (64KB pictures, 8bpp sprite data, etc). With something as resource-heavy as a GUI, one can do without multiplying the size of all the resources by eight. Maybe 256 colour icons are desirable, but it makes zero sense to store fonts at 8bpp, in memory or on disk. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 3, 2012 Author Share Posted January 3, 2012 A convoluted sequence for rendering might be possible. And out the pixel we want, use the result as a table lookup for what gets rendered. But then we're probably talking 3 BCB sweeps or more per pixel written out. But on the other hand, a full blit of a single pixel including BCB read is like 23-24 VBXE cycles. In that time the 6502 can do LDA zp Maybe with some creative thinking some means can be devised to keep the font small and render time reasonable. Quote Link to comment Share on other sites More sharing options...
candle Posted January 3, 2012 Share Posted January 3, 2012 how about putting in the same space 8 character sets instead of 1 at expense of using 8 colours entries? for first font and mask would be 0x01, for second font it would be 0x02, for eight font it would be 0x80 thus although fonts had to be expanded to 8bits, they are condenset again using and mask as a font selector Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 3, 2012 Share Posted January 3, 2012 Hmmm... they're proportional fonts so all the data varies wildly in size, depending on point and character width. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 3, 2012 Author Share Posted January 3, 2012 (edited) That sounds plausible. So then we have available colours 1, 2, 4 .. $40, $80 for text. Although in 640 mode it won't be so efficient. ed- same inefficiency applies to 640 mode. What about if the bits in each byte refer to scanlines though? That should cut the waste... but then we get the problem of XStep in blits being limited to +128 Edited January 3, 2012 by Rybags Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 3, 2012 Share Posted January 3, 2012 The way I see it we're talking about interleaving here? But even if we store the fonts at 1bpp, the pixels still have to be upscaled again at render time to 8bpp, depending on the desired colour. I suppose the zoom facility could be employed here. As for 640 mode: would only go there using a 640x400 interlace. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 3, 2012 Author Share Posted January 3, 2012 Zoom won't help, that's only good for repeating stuff. The idea Candle has is to have 8 fonts sharing the byte, then you AND out the one you want and it's colour index is fixed. Before I toyed with some idea of using cominations of Add & the AND/XOR masking to alter the values but you can't do it because the "0" colour selection gets changed. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 3, 2012 Share Posted January 3, 2012 (edited) Yeah, so interleaved bits in the bytes. I once considered doing something similar with extended RAM in another application, but at the byte level instead of the bit level. Shame zoom doesn't work at the bit level, so you could take a 1bpp source byte, maginify it by eight and use a mask at the same time, yielding 8 x 8bpp pixels in the desired colour. Note: 16x16 256 colour icons are 256 bytes long. We currently have 900 mono icons (32 bytes each) and counting. That's 220KB worth of icons at 8bpp - some resource file. I think any VBXE GUI should come with IDE Plus as standard... Edited January 3, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
candle Posted January 3, 2012 Share Posted January 3, 2012 oh stop complaining and start getting work done Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 3, 2012 Share Posted January 3, 2012 oh stop complaining and start getting work done I suppose I'd better get used to this kind of managerial response if I have any ideas about working in IT. Quote Link to comment Share on other sites More sharing options...
atx4us Posted January 5, 2012 Share Posted January 5, 2012 This is a fantastic resource for the VBXE. Thank you for starting this posting. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 5, 2012 Share Posted January 5, 2012 I suppose I'd better get used to this kind of managerial response if I have any ideas about working in IT. Hey Jon, don't knock yourself, I reckon you would be very good at reading the script off the screen saying "have you put the plug in the wall?", "the mouse is that oblong shaped thing near the keyboard" and "How did you get a fork stuck in the DVD rom?" Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 5, 2012 Share Posted January 5, 2012 Don't forget "have you tried turning it off and on again?" Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 6, 2012 Share Posted January 6, 2012 Lol..Indeed, people just don't realise 1. how dangerous the general public are to a computer and 2. how pointless it is calling a help line.. Those of us on here that had to deal with the public from the support side in anyway know that nothing ever surprises you as to their creative methods of computer / OS destruction. The other side is when you are stuffed into ringing the help line because at no point can you see what they called their pop3 and the fact they used a strange port etc. There you are just asking that little question to save you 10 mins hunting around and the guys reading his script asking you to check all your settings or he won't go on... You sit there livid saying "Just tell me the name" and he's saying "Sir, now be clicking the start button"...Grrrrrrrrrrrrrrrrrrrrrrrrrrrrrr Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 8, 2012 Share Posted January 8, 2012 Colour customisation had to be done entirely via palette manipulation, but it works (after extensive trial and error). Here's a retro colour scheme for WordStar fans: An evening of debugging should see this done. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 8, 2012 Author Share Posted January 8, 2012 You not going to do short character tricks and have full descenders? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 8, 2012 Share Posted January 8, 2012 Like Hell, lol. This was supposed to be a simple side-line project to take advantage of the hardware 80 column mode... it's taken three weeks. Once it's debugged, I'm gonna start running and not look back. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 9, 2012 Share Posted January 9, 2012 Is it possible to deduce the VBXE hardware base address ($D6xx / $D7xx) via software interrogation, or do I need to make two versions of the driver? Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 9, 2012 Author Share Posted January 9, 2012 It's up to you - I'm doing 2 versions of Moon Cresta because hitting registers direct is so much easier than sta (zp),y I do detect by a simple mech of attempting to open the MEMAC window - just put 2-3 known values there first, open the window, store zeros, close, then see if your original data is still there. The way I see it, it's up to the user to keep their core version up to date, so I don't bother checking core version. Re the descender text - with the flexibility of XDLs you could do it with practically no program changes - just have each short line use the same addresses as the one above but with pointer to different charset. Of course the visible screen would grow substantially but the benefit of full descenders at extra height would be worth it. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 9, 2012 Share Posted January 9, 2012 That method makes sense. Indirect stores are no problem, since all the writes go through a central routine, so some self-modifying code changing a single address will do it. The thing that puts me off adding descenders is the extra work involved in designing new fonts specifically for the VBXE version, and since it was MrFish who designed the huge font collection, I'd rather allow him to stay focused on the GUI than impose on him for any further resources for LW at this point in time. However - I do need to write some contributions for the next core pack so - along with a couple of other ideas - I'll add the descender text demo to the list. Quote Link to comment Share on other sites More sharing options...
andym00 Posted January 9, 2012 Share Posted January 9, 2012 How about a macro to add all the VBXE addresses to a relocation list ? And then patch them at run time ? !macro VBXE .VBXERegister { .codePC = * * = VBXERelocationTableTop !word .codePC VBXERelocationTableTop = * * = .codePC !word .VBXERegister-VBXEBase } And somewhere at the end of the image terminate the list.. Obviously, it's not ideal since you need to have enough space allocated for the storage of the relocation table, but that just needs a warning of doom when it runs out of space at assembly time.. That's if your assembler doesn't support relocation tables, in which case I'd just define the VBXE registers as externals, and then patch as you would when doing your late binding.. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 9, 2012 Author Share Posted January 9, 2012 (edited) I'm just using something like: vbxe = $d600 ; vbxe = $d700 video_control = vbxe + $40 xdl_adr0 = vbxe + $41 etc. Then just change which "vbxe" equate is commented for each assembly. equally as well you could just use *= and a .ds for each register in turn although I don't trust that so much, if you disturb such DSects then the whole thing falls apart. Edited January 9, 2012 by Rybags Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 9, 2012 Share Posted January 9, 2012 I've got: vbxe_write sta $d600,y rts ; So I just need to change VBXE_WRITE+$02 to $D7 and I'm done. Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 9, 2012 Author Share Posted January 9, 2012 You'd probably just be better off using the indirection method. JSR/RTS costs 12 cycles plus the extra instruction. STA (zp),Y saves a byte for each store and will be quicker overall. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 9, 2012 Share Posted January 9, 2012 (edited) Heh... that would mean looking for a spare ZP word the main program isn't already using (it already consumes everything from $80-$FF plus a few $5x locations). The time-consuming stuff's all done with the blitter so I doubt it's a major issue. Edited January 9, 2012 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.