Hi, I was doing some tests on the new (Bundle 23) CharAde Engine. This is playable, I think (it's a "Bugaboo" easy clone), although I do not plan to continue its development.
https://sites.google.com/site/plus3code ... ects=0&d=1
Chao
Concept
Re: Concept
Oh I like that, that's really good. Is it using the MAP mode?
Also it looks like you're calling compiled game code, is that right?
What compiler are you using, that allows CharAde to keep working?
Also it looks like you're calling compiled game code, is that right?
What compiler are you using, that allows CharAde to keep working?
Re: Concept
Hi, yes, I use the "new" map mode Thanks for the example.
It‘s compiled with Hisoft BASIC Compiler (+3 version):
https://spectrumcomputing.co.uk/index.p ... 96&id=8249
I used it too in previous CharAde demos and it runs ok with the Engine.
Re: Concept
OK, it must still be using the BASIC implementations of PRINT# channels and System Variables.
Is it making a noticeable speed improvement? Would you mind making some notes on how to use it, then I could add a reference to it to the manual? Mainly, how to make sure it compiles the BASIC but avoids over-writing the CharAde code block.
Is it making a noticeable speed improvement? Would you mind making some notes on how to use it, then I could add a reference to it to the manual? Mainly, how to make sure it compiles the BASIC but avoids over-writing the CharAde code block.
Re: Concept
I think that almost all old, Spectrum native, BASIC compilers (with LPRINT support) should probably work fine. Could it be that CharAde affects the system variables CHARS? The speed is much higher, of course There is no problem in writing some notes, but I will have to resort to Google TranslatorJoefish wrote: ↑Tue Feb 18, 2020 3:57 pm OK, it must still be using the BASIC implementations of PRINT# channels and System Variables.
Is it making a noticeable speed improvement? Would you mind making some notes on how to use it, then I could add a reference to it to the manual? Mainly, how to make sure it compiles the BASIC but avoids over-writing the CharAde code block.
Re: Concept
Thanks.
No, it doesn't affect CHARS. It affects the system variables that control where PRINT # channels go, to divert LPRINT to its own routines. LPRINT is not a simple implementation in Sinclair Basic. Neither is PRINT. Both can be diverted to different functions by messing with the System Variables. PRINT, LPRINT and PRINT# are all just output streams that can go anywhere. It's just that, by default, PRINT points back into a ROM routine for putting characters on the screen. I'm not sure if diverting the normal PRINT function would work in HiSoft compiler though, since PRINT is an obvious function to speed up with an optimised replacement. HiSoft must preserve some system variables, but I don't know which. If you try too hard, you'll come across something that doesn't work properly!
CharAde loads in below the UDGs at 65368. It loads in between 54100-65148. The code block includes the Foreground and Background screen data and everything else, although now I come to think of it it seems a bit of a waste to save that! It ends at a strange address because most of the data has to be aligned to start on a 256-byte address.
There's actually 219 bytes between the end of the CharAde code block and the UDGs, so you could fit a second set of ordinary UDGs in there. I don't know what HiSoft makes of UDGs, but maybe they would still work.
No, it doesn't affect CHARS. It affects the system variables that control where PRINT # channels go, to divert LPRINT to its own routines. LPRINT is not a simple implementation in Sinclair Basic. Neither is PRINT. Both can be diverted to different functions by messing with the System Variables. PRINT, LPRINT and PRINT# are all just output streams that can go anywhere. It's just that, by default, PRINT points back into a ROM routine for putting characters on the screen. I'm not sure if diverting the normal PRINT function would work in HiSoft compiler though, since PRINT is an obvious function to speed up with an optimised replacement. HiSoft must preserve some system variables, but I don't know which. If you try too hard, you'll come across something that doesn't work properly!
CharAde loads in below the UDGs at 65368. It loads in between 54100-65148. The code block includes the Foreground and Background screen data and everything else, although now I come to think of it it seems a bit of a waste to save that! It ends at a strange address because most of the data has to be aligned to start on a 256-byte address.
There's actually 219 bytes between the end of the CharAde code block and the UDGs, so you could fit a second set of ordinary UDGs in there. I don't know what HiSoft makes of UDGs, but maybe they would still work.
Re: Concept
The speed of the program also depends on how it has been programmed. Pancho is compiled, but does not use the map mode but a slower technique: I put the data in a string array and send it to the engine in a loop with
LPRINT array (x TO x + 27)
so if right = x + 1 and if left = x-1, in addition to updating everything else, so that the main animation loop is relatively slow (you can examine the source code, it is in a folder). You could program better and faster (with map mode, etc), but hey, you also have to be aware of the limits
Re: Concept
This thread covers how to mess with the System Variables to divert channels and streams to make them do what you want:+3code wrote: ↑Tue Feb 18, 2020 4:13 pm I think that almost all old, Spectrum native, BASIC compilers (with LPRINT support) should probably work fine. Could it be that CharAde affects the system variables CHARS? The speed is much higher, of course There is no problem in writing some notes, but I will have to resort to Google Translator
viewtopic.php?t=539
You can divert PRINT, PRINT# and LPRINT. They're all the same function really; it's just PRINT and LPRINT default to certain #-numberered channels. One goes to the screen, one to the printer buffer.
You can also divert INPUT, INPUT# and there's even an INKEY$# you can supply with your own inputs, but they're much harder to manage in your own code, which is why CharAde doesn't use them for retrieving data. (You have to use PEEK to get answers from it). But you can use them to return values to BASIC instead of it reading the keyboard.
Slight problem though is BASINC doesn't seem to accept the INKEY$# function as legitimate syntax!
Re: Concept
That was perhaps a bit of an exaggeration. I have done some small tests with LPRINT and the CharAde loaded in memory and these have been the results:
Wye compiler
https://spectrumcomputing.co.uk/index.p ... 96&id=8991
ToBoS
https://spectrumcomputing.co.uk/index.p ... 96&id=8893
and IS Compiler
https://spectrumcomputing.co.uk/index.p ... 96&id=8696
they all need the compiler to be in memory to execute the compiled code. CharAde and the compiler overlap, so these compilers are not useful.
Trisom
https://spectrumcomputing.co.uk/index.p ... 96&id=8905
HS Compiler
https://spectrumcomputing.co.uk/index.p ... 6&id=15564
and Turbo Compiler
https://spectrumcomputing.co.uk/index.p ... 6&id=14759
do not support LPRINT / PRINT # 3
USCHI:
https://spectrumcomputing.co.uk/index.p ... 96&id=8927
apparently it works well, it is the second after Hisoft's, but it is more limited.
FP Compiler
https://spectrumcomputing.co.uk/index.p ... 96&id=8693
used together with the FP Linker (Zeljko Juric):
It is the third one that apparently supports CharAde. Seemingly more limited than Hisoft's.