RFC: Programming #ColecoAdam #FujiNet?

[tschak909]

#ColecoAdam #FujiNet I need to ask from the community some input to clarify some thoughts regarding how ADAM programmers expect to be able to program this thing:

The ultimate goal is to integrate as much into the system, as possible, and make it easy to program, so that somebody can write a networked game in SmartBASIC, over the weekend, if they wanted.

My initial investigations with different versions of SmartBASIC have yielded, shall we say, inconsistent results. Version 1.0, for example, has almost no device I/O outside of the tape drives. Version 2.0 has support for the unreleased AdamNet serial/parallel modules. Version 1.x from Rich Drushel hacked in support for OrphanWare parallel and serial cards, which communicate not over AdamNet but via I/O ports...

However, all versions of SmartBASIC can PEEK and POKE their way through all the EOS functions. So a library of SmartBASIC subroutines can be written to make it easy to use #FujiNet functionality. Thoughts? Are there other options I haven't considered yet? Perhaps patching SmartBASIC to expose the various AdamNet devices via PR# and IN# commands?

Calling from Assembler will be easy, as it will be done via EOS calls.

Calling from high level languages, is also similarly easy, as every available C and Pascal compiler has a facility to marshal calls to assembler routines.

And as far as I can understand, at least the lowest level EOS calls are available from CP/M. (Even if not, the DCBs are still exposed and can be used directly).

So, this leads me to want to put together example code in the following forms:

* C examples in Z88DK.
* SmartBASIC routines
* Assembler examples

Thoughts?

[Pixelboy]

If you want to improve upon SmartBASIC, start with the basics (no pun intended):

 

1) Add a functionality where the running program can detect a keyboard key being pressed without actually waiting for a key to be pressed. In other words, the software checks for a keypress, and if none is detected at that particular moment, then the program keeps on running with the notion that no key was pressed. That is something I always found frustrating about SmartBASIC: I could only do this kind of keypress check with the keypad on the Coleco controllers, but not with the ADAM keyboard.

 

2) Add graphic modes that are actually usable. Let me define tiles and sprites in VRAM, and then display them under graphic mode #1 or graphic mode #2 without having to resort to PEEKs and POKEs. The existing low-res video mode offered by SmartBASIC (with the four lines of text at the bottom) was mildly interesting but you couldn't do much with it in terms of making interesting games. And the higher resolution graphic mode was so badly documented it was basically unintelligible for the kid I was, back when the ADAM was a current machine.

 

3) Let me import data made with external tools into my SmartBASIC project. This is especially true with sounds and music: If a program lets me design music and sound effects, I should be able to transfer that kind of data to my SmartBASIC program, with easy playback options.

 

In a nutshell, If I want to do my own version of Donkey Kong Junior with SmartBASIC and make it look, sound and play much like Coleco's version, I should be able to do it without having to hack my way through the hardware.

 

Once those kinds of "quality of life" options are in place, then we can start discussing such things as "programming networked games".

 

[tschak909]

This seems to point to needing to make a new language.

 

I understand your point, and your frustrations. 

 

So at least, for now, I will try to make good solid example code available. 

 

Trying to get FujiNet support is especially important, because the goal is to get it to every single 8-bit computer and game console. (Yes, this means non-Adam colecovision too). 

 

(One of the important bits of hardware work is working through a nice parallel bus interface that can be adapted to card and cartridge slots)

 

-Thom

[Pixelboy]

My statements were based on my experience of SmartBASIC from many years ago, and those are the downsides of the language I can still remember to this day.