Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Small snippet to make the AY scream a bit
#7
britlion Wrote:Which other architectures are you considering, Boriel?

Would having something like a PAGE # assembler directive work - that makes references to this block as though it was in the top 16k of memory, but makes a separate code block in the file? I assume a zx basic program and .tap file is sorta zx spectrum specific as it is, so there's precedent...
Wel, some ideas:
  • Z80 architectures: MSX, Amstrad, ZX Spectrum clones, Gameboy, etc...
  • 68000 architectures: QL (many people asking for it)
  • .NET To run your programs in .NET (this should be easy)
  • JAVA -> Your program embedded in a browser
  • Javascript -> Like JAVA but easier. I'm seriously thinking it working on these now...
  • C -> Port your program to C so you could recompile it on your arch with less pain. Should be easy using ALLEGRO / SDL. Seriously thinking on starting it...
  • Commodore 64 (may people asking for it)
I was even considering PS3 (yes, I own a FAT PS3 model). But since Sony removed the "Other OS" option, I stopped.

I tried hard to keep Sinclair BASIC compatibility whilst expanding the language. So people wanting to port their old Speccy BASIC programs should find it easier that starting their programs from scratch. But definitely, people make new programs should use the FreeBasic-like (not 100%) syntax (Functions, subs, etc...).

Problems: Some functions might definitely not be portable. E.g. ATTR (which color value to return on 16x16 different color set?), SCREEN$, POINT etc. These functions are external Wink ones. That's why you have to use --sinclair or #include to use them. External functions and subs need parenthesis since they are just normal .BAS files (Visual Basic allows calling SUBS with no parenthesis but I think this will clutter the language syntax and the parser). So, to maintain syntax compatibility with Speccy BASIC, some inner subs like RND(), PLOT(), DRAW(), INKEY$(), etc... has been integrated in the BASIC syntax as inner (integrated with the compiler syntax) functions and subs.

Those INNER (not external) functions, like DRAW, PLOT or BEEP might *not* be portable. A clear example are VAL and INPUT. INPUT sub is not compatible with compiled ZX BASIC because It's impossible to call the ROM routine which needs INTERPRETED Basic. I could implement it from scratch (as done with PRINT), but then a simple PRINT / INPUT will take a lot of memory. Hence, an INPUT() routine very like FreeBasic was implemented.

So porting basically is planned like this:
  1. Create a directory ports/ in the compiler structure
  2. Create a subdirectory for each architecture within ports/ directory e.g. ports/spectrum48k (yes, spectrum128k could be a different architecture)
  3. For each architecture port dir, there must be a library-asm and library/ directory. There could be a generic library/ for all architectures provided they don't use ASM...END ASM
  4. For each architecture, the backend/ compiler directory must be copied in ports/<arch>/backend and re-implemented for each architecture.
  5. Invoking the compiler with --arch=<arch> will check if /ports/<arch> exists and exit with an "Arch. not supported" error if not.

Obviously, I can't do all the above alone. I'm still planning things in the compiler before releasing a ZX BASIC Backend SDK to develop ports.

BTW: to save memory, a --use-internal-print flag will be implemented soon (replacing my print routine with the standard ROM one, but disabling BOLD, ITALIC and OVER 2/3 features).
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 3 Guest(s)