ROM BASIC replacement?

[c704710]

I don't suppose a ROM/BIOS version of freeBASIC could be engineered from freeBASIC?

What I have in mind is statement compatible versions of freeBASIC for z80, 690x, 6502 CPUs that are 8K or 16K in size, suitable to replace the BASIC in ROM/BIOS files used in emulators or to include in real chips used in real hardware for hardware remakes. This would satisfy half of the legal issue of needing a system BIOS for ancient systems (such as Ohio Scientific, Commodore PET, TRS-80) and system remakes (replica 1, Cyclone Coco). I'm not necessarily looking for a finished BASIC, more of a system to arrive at a finished BASIC. A program when run would ask the user such things such as if the language is tokenized and read a list of tokens, if white spaces are required after commands, read a list of variable types, read a list of commands compared to standard commands, read a list of commands compared to a memory map, if abbreviations are allowed, read a list of commands compared to command abbreviations. Basically, the program would assemble lists into a recipe to make a finished BASIC based on user supplied parameters. Not only for making say, a specific 6502 BASIC for the Ohio Scientific Challenger C3P that runs existing BASIC programs, but hypothetical systems too. Say, a 6809 BASIC for an Apple ][ with a 6809 CPU. Or a BASIC with object code commands for Commodore 64. This relies on the user to do the reverse engineering by simply studying the BASIC on a real system (type commands, see what they do). Instructions on how determine details _without consulting a manual_ would be given to the user. Such as enter "FRE" or "FREE" and note the number, enter "10 PRINT 1", and enter "FREE" again. If the number is 5-7 bytes less, then this BASIC is tokenized, 10-9 bytes less means it is not. Legally clean Libre BASIC. Of course an actual basic program could be designed to do this automatically, but that's probably a DMCA violation.

[MrSwiss]

I don't suppose a ROM/BIOS version of freeBASIC could be engineered from freeBASIC?

As I am fond of saying: everything is, at least in theory, possible ...

However, the seeming assumption by you "FreeBASIC = BASIC Interpreter" is already incorrect, since FreeBASIC is a Compiler.
All the ROM-BASIC's (IBM/Apple II etc.) I'm aware of, are interpreters, not compilers.

A compiler produces binaries (????.exe on WIN/DOS), which in turn, require an OS to run on (WIN/LIN/DOS/OSX etc.).

This would mean in practice:

• - You'll have to start off, by writing your own BASIC-Interpreter (as a first step)
  - ...
  - ...
  - Hooking it into the respective BIOS-load-sequence ...

Aka: In short, a major project ...

[marcov]

Having a generic interpreter developed for that purpose conform to all the architecture and memory restraints of the named architecture (including 4kb PET) is already quite a challenge.

Considering retargetting a 32-bit compiler to function as interpreter (cough JIT) is insane.

[caseih]

It's pretty amazing what you can do with small amounts of CPU and memory. They had whole Pascal interpreters decades ago. An interpreter for most the the whole, modern FB dialect for embedded processors is certainly possible. This would be an implementation though, not a port.

There's a neat project that has put a full Python interpreter in flash ROM on embedded processors like atmel and arm. Of course these chips are far beyond the old chips of the 70s and 80s.

[marcov]

It's pretty amazing what you can do with small amounts of CPU and memory. They had whole Pascal interpreters decades ago.

Probably you mean Pascal bytecode interpreters. (UCSD Pascal)

interpreter for most the the whole, modern FB dialect for embedded processors is certainly possible. This would be an implementation though, not a port.

Hmm. Even then (and the implementation not port bit already confirms what I said), you'd be porting a compiled dialect to an interpreter. Not the same thing.

There's a neat project that has put a full Python interpreter in flash ROM on embedded processors like atmel and arm. Of course these chips are far beyond the old chips of the 70s and 80s.

Specially engineered subsets on relatively large embedded devices yes. Arms like RPI run full pythons.

[D.J.Peters]

Hello c704710 from time to time I do port the FreeBASIC language on my MC6803 retro computer project also.

var x = sin(M_PI*.33333) was really slow but I use the APU AM9511 2 MHz from 1979 now.



ebay: http://www.ebay.com/sch/i.html?_from=R4 ... 1&_sacat=0

Next weekend I build my own video chip may be the VGA timing H/V snyc and pixel/RAM read clock from an Altera MAX II CPLD.
(ALTERA CPLD EPM240T100C5 = 1$ from china)

I love the retro stuff because im retro also 1964 made in germany ;-)

bla bla bla

Joshy

[caseih]

Specially engineered subsets on relatively large embedded devices yes. Arms like RPI run full pythons.

If by subset you mean subset of the standard library, then yes. If by subset you mean the language itself, then no. MicroPython is practically all of the Python 3 language.

As far requiring relatively large embedded devices, well, yes and no. It requires at least 256k of flash, 16k of ram. I'd say that's pretty small, even by 1980s standards.

Some have drawn a distinction between the FB compiler and some theoretical implementation of a FB interpreter. But in the case of a ROM-based system, probably a tiny embedded chip, having a self-hosted compiler doesn't make much sense. Having an FB interpreter (probably byte code) would make much more sense. And I would argue it's as much FB as the FB compiler is.

EDIT: Pretty impressive stuff, Joshy. Can you talk more about it? Are you making an FB cross compiler that targets this processor?

[shadowolf]

Just a thought on a possible approach to get a Freebasic interpreter. Would it be possible to build an interpreter that used FB intermediate representation data structure?

The overlap between a compiler and an interpreter sort of share a lot. Unfortunately, I don't have enough of a solid background in compiler theory nor the FB source code really to even suggest this as a possible pathway. But it seems at least naively you should be able to build something that could interpret the AST. like, Cut FB off right at the emitter stage and pipe that representation of the program into an interpreter.

[jevans4949]

One would probably be better off starting with a free basic (not FreeBasic) interpreter, rather than a compiler. I did google this the other day, and found there are quite a few open source ones. Although I didn't bother looking into them.

You then have to decide what to do about the quirks of each Basic version, some around the hardware quirks of the machines they were built for. And all the POKEs for assembler language that people did at the time.