Can the Plus features be used from basic? Maybe using a RSX library?
The B-Asic RSX extensions are a pretty good way to access the new hardware.
Get B-asic v3.4 here :
http://www.genesis8bit.fr/frontend/programm/b-asic34.zip (http://www.genesis8bit.fr/frontend/programm/b-asic34.zip)
Has anyone considered creating a Locomotive Basic 2.0 (for plus), add another 16KB ROM with the additional commands, and adding B_ASIC commands natively, graphics commands for games ('blitting' multi-colour backgrounds, custom multi-colour fonts, etc, maybe derived from 8bp), and maybe better structured programming (DEFPROC/multiline DEFFN/etc)?
Can we even replace the BASIC ROM easily without hardware modification (i.e., just using an external ROM, like PARADOS over AMSDOS)?
Might be okay as B-ASIC needs 128KB, but in ROM it (or a subset) could work on 64KB.
Quote from: genesis8 on 13:38, 09 December 20
Get B-asic v3.4 here :
http://www.genesis8bit.fr/frontend/programm/b-asic34.zip (http://www.genesis8bit.fr/frontend/programm/b-asic34.zip)
I get URL not found on that link
Corrected, the file had some letters in upper case, not the download link :doh:
Or this link...
http://logonsystem.fr/html/engdownloadlogon.htm
QuoteHas anyone considered creating a Locomotive Basic 2.0 (for plus), add another 16KB ROM with the additional commands, and adding B_ASIC commands natively
This is what Amstrad France offered us to do in the early 90s.
We declined because it was a huge work and the machine was really disappointing and doomed to commercial failure.
It is easier to add a rom which handles the most basic additional instructions via the RSX.
QuoteMight be okay as B-ASIC needs 128KB, but in ROM it (or a subset) could work on 64KB.
Since version 3.0, the B-Asic needs 128k in order to provide a "bank" of 128 additional sprites without using main ram.
But also to provide a second "crtc" screen page, still without consuming the Locomotive Basic central ram.
Version 3.5 is not finalized. I would have to get back to it :-)
I was waiting for the correction of a winape bug. Thank you Richard for beta 3 ! ;D It will allow you to create tiles, tile maps, map sequences, for scroll management, as well as the management of batches of graphical events that can be defined by line.
I still have a reflection to have on the problem posed by the difference in processing speed of the new "autonomous" functions of B-Asic in relation to the speed of the Basic interpreted.
For example if we define the handling of a collision between 2 sprites (or super square sprites), the collision manager will by default update the variable (passed by address in the command via @) faster than the basic can read it to handle it.
The variable is updated, but the basic can be too slow to handle the events associated with a collision.
However, it remains possible to define that the collision is not managed automatically, so that the B-Asic is at the "rhythm" of the Basic.
This problem arises for all the things that the B-Asic does apart from the Basic.
For example, if a path is defined for sprites, they will live their life and move alone, at each frame, on this path, which can make management difficult via Basic.
And that's why there is currently a way to basic control every step.
Thanks for that. So Amstrad France had the sense to try and make the best of things, but there was no point (the plus range deficiencies are another topic though).
I did think the plus sprites could be more smoothly animatable if you did a 'sprite diff' update rather than rewriting all 256 pixels each frame, as not every pixel need be animated in each frame. A very basic implementation could have each byte of sprite data being 4 bits of sprite data, and 4 bits pixel skip, or you could use RLE or whatever Amiga .anims used, etc. Maybe it doesn't save much time compared to just thrashing the entire sprite data to the ASIC, and you only need to animate a sprite every 5-25 frames anyway, which you can interleave already.
Quoteeach byte of sprite data being 4 bits of sprite data, and 4 bits pixel skip
Already taken ;D
The B-Asic stores 128 sprites in 16k using the 4 unused bits for each pixel.
The sprite numbers 0 to 15 relate to those of the asic, from 16 to 79 the "ram fast" sprites, and 80 to 143 the "ram slow" sprites.
The idea is good to manage the differences between two sprites.
However, if you have to do a process that reads the 4 bits of each pixel to add them to the transfer pointer for the next pixel (while managing the end of the sprite), this can turn out to be consumer, while not changing the size occupied by the sprite.
Furthermore, this technique assumes that only a B sprite replaces an A sprite, but in animation there is often a tree structure and therefore this is not always the case (for example a character who runs and stops to return to stop position).
However, if you want to do a differential transfer, I think it's possible to do it by creating sprite-specific code (it's efficient, and sometimes less space-consuming than a full sprite). The sprite no longer exists as data, so you have to use a function that stores it that way.
It is rare that an animation needs to be refreshed to the frame.
But if you update your sprite in several times over several frames, this can theoretically be seen because the sprite is displayed at each frame. (Amstrad spared the cost of providing more memory in Asic and vectorizing sprites, which would have made it possible to handle this sort of thing easily).
It is of course perfectly possible to decompress a sprite directly from a file in the Asic.
It all depends on what you want to do.
I did once ponder the idea of making an entirely new BASIC cartridge with a Plus optimised implementation instead and with better support for things like expanded memory (I had in mind something like SAM Coupe BASIC that can store your program anywhere in the entire available RAM) and something probably more game oriented than classical BASICs were.
In the end though it seemed a lot of effort for questionable returns. As Longshot says a ROM with RSX commands is probably a reasonable alternative.