Concept

Show us what you're working on, (preferably with screenshots).
Post Reply
+3code

Concept

Post by +3code »

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 :D
User avatar
Joefish
Rick Dangerous
Posts: 2058
Joined: Tue Nov 14, 2017 10:26 am

Re: Concept

Post by Joefish »

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?
+3code

Re: Concept

Post by +3code »

Joefish wrote: Tue Feb 18, 2020 2:51 pm 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?
Hi, yes, I use the "new" map mode :D 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.
User avatar
Joefish
Rick Dangerous
Posts: 2058
Joined: Tue Nov 14, 2017 10:26 am

Re: Concept

Post by Joefish »

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.
+3code

Re: Concept

Post by +3code »

Joefish 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.
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 :D There is no problem in writing some notes, but I will have to resort to Google Translator ;)
User avatar
Joefish
Rick Dangerous
Posts: 2058
Joined: Tue Nov 14, 2017 10:26 am

Re: Concept

Post by Joefish »

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.
hikoki
Manic Miner
Posts: 576
Joined: Thu Nov 16, 2017 10:54 am

Re: Concept

Post by hikoki »

Nice scroll! It'd be cool to see the Pancho Bros demo compiled
+3code

Re: Concept

Post by +3code »

hikoki wrote: Wed Feb 19, 2020 9:44 am Nice scroll! It'd be cool to see the Pancho Bros demo compiled

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 :lol:
User avatar
Joefish
Rick Dangerous
Posts: 2058
Joined: Tue Nov 14, 2017 10:26 am

Re: Concept

Post by Joefish »

+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 :D There is no problem in writing some notes, but I will have to resort to Google Translator ;)
This thread covers how to mess with the System Variables to divert channels and streams to make them do what you want:

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!
+3code

Re: Concept

Post by +3code »

+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.
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.
Post Reply