Zikzak - crummiest 8bit console/computer ever .. but I'm making it!

[levi]

Actually, I was thinking there may be some value into calling a C function, since it means you could write stuff in C and not be stuck with asm. You'd need to build your cart code as a dll rather than as an executable, at a guess.

I'm not really an expert in this stuff, just spent time hanging around people who are, and have an ability to google processor instruction sets. But I'll gladly look at anything you want to PM me or to post here. Just run your source code through cpp to get rid of those conditionals.

 

[skeezix]

I've not had much time, but I can say .. the code is doing:
.assume ADL=1
JP (IY)

... looks okay to me, offhand. The .assume ADL=1 tells the assembler to use the 24bit addressing and such. I should trt with jp.lil to be specific though, but another night.

RL is too busy of late :/

jeff

 

[levi]

From what I read in the docs, the processor starts in z80 mode, and that assume just tells the assembler to write out ADL (aka 24-bit) numbers. When the processor hits them it'll still be in z80 mode, so it'll probably barf on it if I've read the docs at all properly (probably not). My JP.LIL instruction switches the processor into ADL mode, as well as doing a jump (but you can just jump to the next instruction if you want).

That's my understanding anyway. If it's working for you, ignore me.

 

[skeezix]

yeah I've had a similar suspicion or a couple days since I started banging on this again; just no time to get near the damned thing in awhile :/

See, I can actually jump around in the same region of memory no problem; jumping from 0x0Cxxxx to 0x1Cxxxx is blowing up but I've not had a time to step through a disassembly and see where exactly, but its very interesting that crossing the page boundary is doing it. Screems ADL or at least instruction set problem, right?

The assembly being generated is a bit odd and trickier to follow but I'll go through it relatively soon. There is some extra surface area.. the tools are not bad, but they are known to have some bugs; one thing is the startup code rather assumes starting in the first 64K, rather than any old 64K; ie: if you assign ROM to be anywhere other than starting at 0x00 (be that in ram or flash or rom or whatever), it gets screwy. It doesn't look too hard to fix that (just put in some switch-to-ADL-mode in the top of the startup code but maybe theres gotchas (why wouldnt' they have thought of that and added a checkbox...) -- but maybe I need to test, and maybe the .assume ADL=1 implies some of that. Still, assigning starting PC to some non-0x00 value produces a bunch of interesting errors. I'm not sure if its doing PIC or non-PIC code, but I think its non-PIC, which makes it annoying (though faster.)

A brute force workaround (which I might go with if I get lazy/time-constrained) is just to let the cart space be assigned really low (ie: so boot the firmware at 0x0000 and layer in the cart space at say 0xF000+ or something, so that the firmware can jump into the cart, and th cart first thing is go full ADL mode if it wants or something. I had intended the cart header to have a ADL or Strict-Z80 flag so the cart could flag preference, but what about the idea.. put the built in ram and flash on/off Booleans there, along with settings for registers .. so the cart could request a specific layout of memory and chipselects? The firmware would startup and say live in the bottom 8K or 16K of the memory space, and check ghe cart for paramaters, and jump into the cart at 16K-in (or wherever the cart wants to be.)

tuff like that would work, but may be cheap. Course, it would also make stuff like CP/M a lot happier with less fiddling, since CP/M really likes to live in 32K or 64K Z80 machines.

(FWIW, I fiddled a bit and _DID_ get Infocom Zork1 working for a few minutes, once. Muahuahua.)

The ideal solution will be when I get some hacking time at home and fiddle with ADL mode and such again, and maybe its just a couple opcodes away form easy success on that front.

Ahh, real life,

jeff
[doublepost=1465521480,1465519880][/doublepost]See application note an0339.pdf .. some good notes in there.

 

[levi]

Yes, as far as I've noticed, ADL JP direct and z80 JP direct share the same opcode. Just the first one is followed by three bytes, and the latter only two. If it's running in z80 mode, because it's a little endian system it'll ignore the MSB and assume that's part of the next instruction. Thus, it'll effectively jump in the current MBASE. If you did something else that took a 24-bit argument that didn't modify PC, it'd end up treating the MSB of the argument as the next opcode and get in a horrendous out of sync mess, I'd bet.

I can't guess why non zero but still in zero MPAGE produces screwy results. It does initialise PC with the right value right? I know all old 6502 systems always started at 0 where they usually experienced a JMP up to OS space, because zero page was full of other important stuff - because the processor has special zero page addressing modes for instructions which usually take a clock tick less. Interrupt handling was usually done in there for instance.

Edit: I've read about mixed mode memory but not really grokked it yet. I'll have a run through that appnote and see if anything sticks.

Edit2: Okay, it does say 'The compiler directive .assume ADL=0/1 will change the CPU's current memory mode. But it also makes statements such as 'The CPU can only make Persistent Mode switches between the ADL and Z80 modes as part of such special control transfer instructions as CALL, JP, RST, RET, RETI and RETN, or as part of an interrupt or trap operation.'. I suspect that first statement is a typo, and it actually means it just makes the assembler start spitting out ADL instructions regardless of what the CPU expects, since that's how I read what it suggests elsewhere. You can also do individual instruction mode switches using suffixes such as .LIL, but I don't know how those are actually assembled - it doesn't say.

I'm a little concerned by the section 'Additional linker directives' specifically, 'the startup code'. I dunno why it needs to copy stuff from ROM to RAM, so I'd try ignoring it to begin with and see how far you get without it.

 

[skeezix]

yeah 6502 zero page was an awesome hardware hack; always loved that, and moving things to page zero so you could save some cycles. Good times

I'm more used to 6502 than z80, but went with z80 on the ZZ so it'd be some learning, and because of course the z80 is still widely available. I didn't realize at the time that a company is in fact making 6502s (under another name) .. but I'm still glad I went eZ80, as its been a very fun little chip to mess with.

I think you may be right; I'm home now and hoping to sneak away tonight for a tough; have to work a couple hours still (uugggh), but I just want to change my JP to JP.LIL and see; I had thought before that the .ASSUME ADL=1 would be sufficient, but I think that's just setting the CPU mode (ie: wider registers etc), but the assembly code is still the same. JP.LIL wil set the CPU mode permanently, but also will handle the full jump. Otherwise a JP is just within the mbase, which I didn't properly set up (since I've been generally working fully in ADL mode and ignored it)

My plan or the firmware is really just to act as a simple bootloader/bootstrapper; it should just chck the requirements (ensure memory is present etc), determine mode, and jump to the cart (if present); it should also be able to go into flashtool mode, skeebasic mode, monitor/direct-code mode, and of course the various test modes. Monitor mode should allow arbitrary mode setting, register query, jumping to run some code, etc. So a BIOS-routine set for firing up code, for sure.

(and BIOS routines for initializing the framebuffer, serial, changing video modes, rendering text, uploading sprites, etc etc etc)

Going back and forth with ASM and C rather suggests I should know the subtleties more .. *eep* The limits of attacking 25 problems at the same time instead of just one

I do like the idea of the cart having the flag of what mode it prefers, and what entry point, etc; it'd be cool to have a pure-z80 cart, and a ADL cart, and just work by switching. (ie: I'm dieing for a CP/M cart running original MS Basic and some games, and a full ADL mode cart that runs some modern unix-like OSes..)

edit: FWIW, .. JP.LIL (%0xC10000) ... if memory serves. Or the old LD MC/JP business.

 

[levi]

Yeah, configurable z80 or ADL mode should be doable, but first of all get it jumping to cart address in ADL - that seems the simplest thing to do first. To get there in z80 mode, you need to set MBASE, and you can only do that from ADL mode, so I know at least to do that you need to switch to ADL, do the magic then switch back - the only thing I'm worried about is when does MBASE changes take effect? If it's immediate it won't go to the next instruction when you exit ADL mode, so you'd need to make sure you're lined up with a page end when you do that, or perhaps it waits for a JP instuction, which would be easier to work with.

But I think ADL mode should just work with a JP.LIL. So I'd try that alone first.

By the way, I'm suspicious of those brackets around the address there - that reads like indirect addressing, where it pulls a value from 0xc10000 and jumps to that address, which is not what you want. Does it assemble without them?

 

[skeezix]

alright, had a quick fiddle .. RL can wait just a moment, right?

yeah, so putting in a JP.LIL %1C0000 (or whatever address) is sufficient. Yeah, the JP ... (foo)... is for when using a memory location and stuffing the address in there, for when the monitor/flashtool want to jump around without recompiling every time. But just to keep it simple I put in the embedded absolute address to see, and fired up the disassembler debugger.. and it works fine, that way. The code jumped to is stilled messing up, but I can confirm its getting there.

ie:

Going to 0x1C0000 is the .reset and .startup and so forth sections prior to the actual C code (the main() for the cart, say); its getting confused in there. If I set up a main that just itself starts setting some values in RAM (like addr X to be 1, X+1 to be 2, and so on), then it acutally manages to get to 1 of them and then blows up; only taking a moment to step through the disassembly, it seems to be properly getting to the right bits, but the CALL's are going awry; the compiler is optimizing in a lot of stuff.. I didn't trace the call destinations but surely some of them are going out into space. ie: perhaps some of that code is non-PIC and making assumptions about MBASE or something between the modes of what it thinks its in versus what done to it. (then again, maybe another variant of JP.SIL or something that uses the long format, but returns to Z80 mode, and then entering the startup code would be the way to go, or doing the MBASE set and go.

(or act like a real bootloader, and in fact copy the CODE and so on segments from the cart into some scratch-RAM and run it there; thjats more involved, but Zilog does include some code for that.. which is highly interesting but no time to examine yet.)

Notably, theres a __frameset function being CALLed whenever you enter a block (like a { brace, or other blocks), and thats going off into space.. let me look that one up if I can find it..

Or maybe set mbase to 1C, and do the one-instruction jump to 0x1C0000 returning to z80 mode, and let it go from there to set itself up.

jeff

 

[liveunderwater]

I'm having trouble defining PIC/non-PIC code. I've been following along here for some time and am very interested in the Z80 architecture. Are we talking Position Independent Code? Sounds like it based on the issues with the address start points stemming from ADL mode. I'm mostly familiar with the original Z80 which according to, The Z80 Microcomputer Handbook, always starts at 0x00 and then branches from there. Great read so far, I want to build one

 

[skeezix]

levi - you know, if I just wrote the carts in asm, it'd be 'easier' that way; this interplay of the C compiler to the asm is the problem here; just soooo much crap to look at to trace through where the hell its going using the LD A, LD MB, A, JP.SIS works too, gets into the right area. But seems like a few thousand opcodes later its going off into space. No time to trace more tonight, have to get some work done (sigh!) .. and got my parts to rebuild the 3d printer so need to work on that sometime (that'll take a few days to rebuild .. ugh.) Still, for _sure_ jumping to the cart is working, just need to nail the code down. (course, its rather always been that way .. I proved long ago I coudl read/write to the cart, before calling the pcb workable; now I've got the cart flashing stuff right in the firmware, it just makes me more determined to get the BIOS->cart jumping actually working nicely .. can't be that much work... doh ... time time time....

liveunderwater -- yeah, precisely; I'm not on top of Z80 or eZ80 assembly as you can see; surely a lot of the code looks relocatable (PIC), but also surely some of it does not; theres probabyl a convention at place where the majority of it is safe, but some specific bits are not and I don't know the convention. Zilog has some really good docs, but also some big holes they rather assume we know

The above is a lot of wildly guessing, as I just don't have much free time right now, so I'm mulling things in the head while sitting on my phone or at lunchbreaks or etc etc, and as you know this is all trial/error stuff where you end up slamming some code in and seeing what happens. Time consuming I've spent most of the project time working on the hardware and the test cases that go with it; the thread is so long its hard to find stuff; I should add youtube links to the zikzak.ca webpage if they're not there now, so its easy to see some of the video tests and so on. But hey, as a side effect, I've got working ps/2 driver code and so on, which is awesome.

As mentioned, if someone wants to get in at this bare metal stage, I do have some spare parts around, but it'd cost a bit (ie: the parts aren't cheap for some).

But one option is .. I did long ago whip up a simple test pcb for the eZ80 and th STM32 .. ie: those two boards, jumpered together, can act as an old zikzak rev1 or something; but you don't need all that, if you want to just goof around, you could just have the eZ80 board, and an eZ80 mcu, and drop on some mono caps and a couple other passives (crystal, etc), and its 'good to go'; to make it run you'd then have to feed power (use a proper bench power supply, or use an FTDI-basic from ebay for $5 and uts ies 3.3V out and also thus get serial over USB to talk to it.) The trick then is flashing it of course..

Right now, I'm using the official Zilog flashing kit which is a bit of $ (ot a huge amount, but its like $75 or something, I totally forget.) Another option is building your own ZDI tools, which is more a drag than I thought so; but a dude just put up a hjackaday project for it, so its feasible, anyway.

This is one of the reasons I'd like to get carts going better .. makes peoples lives easier; no need to flash the firmware if they don't want to, just live in cart-land. (An easy out of course is just to map the cart to 0x00 and have no "BIOS" at all on the eZ80, but thats much less fun. ie: It makes it hard to burn carts, when you need a cart in place just to fire it up and load the burn software from...)

Hmm, for that matter .. I should dig out some CP/M code again see if _that_ does anything; no C compiler there, its all hand rolled ASM and you can build it with good old OSS "TASM" I need to customize a lot of the code (ie: it expects floppies, a serial or video display etc), but I was able to bring it up in pure-memory briefly once, just to see it 'run'; but hacking in a faked up storage (to RAM, say), with serial console should be doable, and get some text out. Lemondate Stand and Zork, oh baby But the end goal is being able to build carts with straight C (or ASM of course, always lots of choices!), since its so much more efficient on time, and easy, to knock out code

jeff

edit: Here is the official tool I use, as its 'ethernet' based (ie: it pluhgs into your network and talks IP); this means runing the ZDS II official toolchain in virtualbox on linux works fine, since it doesn't need to fight with USB or other pften screwed up stuff in VMs.
http://www.digikey.com/product-detail/en/zilog/ZUSBOPTSC01ZACG/269-4664-ND/1236589
[doublepost=1465532365,1465531870][/doublepost]Let me know if any pics are needed, or if anyone wants to see anything in particular, rather than my random blathering on I go in phases, swinging from one aspect to another as I need to, or as they interest me

 

[liveunderwater]

I'll tag along in the forums. At the moment I'm concerned with building a BeagleLogic LogicAnalyzer to troubleshoot a Galaga Arcade machine that is having random, nearly impossible to troubleshoot, issues. On top of that, a friend recently tossed me a TI-99/4A that I can't seem to stay away from. Still, most of my reading is relevant to the Z80 architecture at the moment. Albeit, the Z80, not the eZ80 or any of the variants with that 24bit address bus. Sounds like the biggest thing holding me back from the ZikZak is the flashing kit. The main reason I would like a ZikZak would be to dumb Galaga proms. I may be interested in that bare bones ZikZak rev1 but at the same time I'm intrigued with the current level development you have going on here.

 

[skeezix]

What sort of Galaga issues? I'm no Galaga expert, but there _Are_ those people around as it is one of The Games. Like Ms Pacman .. you can rhyme off the usual 20 issues it has and peopel will tell you exactly what to fix. Just have to find the right forum

I've seen a fair number of character PROMs go bad and such, so graphics are perma funky; or a bad RAM so that its glitchy after a certain amount of play/demi time, or in certain quadrants of the screen, etc. Or fun stuff like a cap thats gone sour so you get intermittent issues until (or after) or warms up.

Or the issue all old boards get where the contacts are flaky between intyerboard connects or the chip sockets, so give the board a good twist and reseat all the chips gently, to clean out any bad contacts. Even contact spray can help, but its messy so I don't advise it.

An audio probe can help too, so you can just poke around and see if theres digital action in the right places, but if its mostly working thats not so useful (audio probe is just good to see if the CPU or RAMis 'alive at all' sort of level of debugging.)

A logic analyser to watch opcodes going by is pretty reaching it for a Galaga; its not using serial busses or anything, so you're really talking about watching the RAM and CPU requests and such, so an oscilliscope might do you fine if you have one; or if you have no o-scope or logic analyser, I'm not sure you'd want to get a LA first; a scope is the more general purpose tool (and more pricey too), but many (even bottom end) scopes these days can do a lot ofg logic analysis stuff in them.

A portable scope is cool too, but depends if you're an electronics nerd, or just fixing up a galaga and hope never to do that again

jeff

 

[levi]

using the LD A, LD MB, A, JP.SIS works too, gets into the right area. But seems like a few thousand opcodes later its going off into space.

Ah, neat. Presumably you need to do that in ADL mode, since according to the docs MB isn't writable in z80 mode. And good point about JP.SIS - I'd forgotten that you could do the switch and jump in one, so no worries about being aligned with anything. That looks like the code you need to get in-cart in z80 mode. If you want OS routines to be accessible from z80 code you'll probably need to populate that cart mbase with some vectors filled with JP.LIL instructions back to OS code in ADL, which presumably finishes with a RET.SIS (or possibly a RETI, not read up on return instructions yet). Presuambly if you don't change MBASE in ADL side, it'll still jump back to the right address space when you do that RET.SIS.

One vaguely helpful thing about processors being so simple is that you can assume that if it gets where it's meant to get, it's all okay so far, and any problem must happen later. If you want to fire any disassembled builds at me, I'll gladly take a look. I'd still like to see what that JP.LIL instruction looks like in bytes, as I don't really know how those single mode switch instructions are encoded - how much space are you going to need for each vector?

As for Galaga boards, I'm never touched one, but all my older hardware fixes have been restricted to fixing leaked electrolyte so far (except for a PS1 which experienced what happens when you flood a bathroom, and just needed a few arc marks cleaning from the mains switch contacts) - a galaga board won't have batteries in so that's good, but it'll still be packed full of electrolytic capacitors. In general, that vintage of caps have less of a tendency to explode compared to ones made in the late 80s, probably because they used to cost more, but they can still dry out i think.

 

[liveunderwater]

As for Galaga. We rewired for a modern switching power supply. Getting ~5.2 volts across all ICs but one that we swapped(we have four non-working boards now, one that we are concentrating on, three that we swap parts from) All socketed chips have been cleaned and reseated and/or swapped from another board. The board we concentrate on now was purchased "known working," plus we have the board that came in the machine which was working when he got it (It is in fact my friends machine). The harness had a really beat up edge connector so I crimped in a new one. I got the cpu/video board schematics printed out from a 600dpi scan to the size of the wall next the the machine we are working on for reference. We have a logic probe but it doesn't have audio, and is terrible at showing toggling. I've gotten better logic results with my multi-meter. No oscilloscope at the moment. I went for the Logic Analyzer first because I want to look at the address and data busses to see if they are glitching, floating, stuck somewhere. I'm suspicious of the custom master bus controller IC at the moment.

The first time we got it up and running after installing the new PSU we played it for more than six hours, it was great. The next day, however, garbage. We are currently getting random results from start up. Sometimes it boots and is playable for up to ten minutes and then freezes. Sometimes it freezes with the star generator still working, or with only the fighter being movable. Or, the machine reboots constantly instead of coming up at all, or does that for a while and then freezes. Every once in a while(rarely) we just get garbage on the boot.

I convinced the owner to get a repair kit that came with the electrolytics, the resistor networks, and new sockets for everything. I gifted a Aoyue soldering station to the owner a decade ago for his birthday. I only just got him to open it for this project and it was me that used it for a quick fix on the edge connector before we completely replaced it. Because it is his board, and because he wants to learn skills with this project we have yet to replace even the resistor networks which we have several of that are bent over and possibly causing intermittent bad logic.

Big Time electronics nerd here. Two favorite magazine subscriptions = Nuts and Volts, and Servo. Unfortunately, a scope has been out of the budget. I already had a BeagleBone, so making the step to ordering parts for the BeagleLogic cape wasn't a huge stretch. I have more recently than that discovered another project that aims to use the BeagleBone PRUs as a scope however so that may be in the works down the line.

I really should be talking over at the KLOV forums but through combing the internet for Galaga error references I kept ending up find a bunch of "Holier than thou" type posters on the KLOV.

This here is the only forum for me. Literally.

So, there you have it, the reason I need to not ask to build a ZikZak at the moment. But man does it ever keep me learning the Z80 arch. Thanks again for that.

 

[skeezix]

Problem with logic analysers is they only do logic high/low (based on some reference determination); they dont' show analog .. ie: if your logic high isn't high enough, or if its sinusoidal instead of square wave, etc. I find LA is good for analysizing logic on a 'known good' connection .. like, you're building a protocol or want to observe a protocol, but know the board is okay. But if the board is unknown, then the LA may just add more surface area to the uncertainty....... or maybe it'll just help, who knows?

I have a Salae LA, which is cheap and pretty awesome. But yeah, should be able to build one with an Arduino or Beagle no problem, and should be pretty good. Beaglebones are awesome

Might be some bad caps causing flaky power (micr-brownouts?) on chips, or maybe your code-ROMs are gone funky... sounds like you got a good handle on it though, so good luck; its great to bring life to an old arcade board

You could find some avr-fanatics and such too, and the guys on the eevblog forum, and lots of good electronics sites.. but yeah, this forum (gp32x, openhandhelds, openpandora, all these that have been evolving for a decade or more) are a unique place, for sure.

jeff

 

[liveunderwater]

Thanks jeff, all good points. Especially that an LA is not going to show the difference between a sinusoidal and a square wave. Certainly something that I need to look at with a scope. If I feel like bringing up Galaga more on these forums I'll start a thread in the appropriate place. Until then, let's talk about that ADL some more. I'll have to get the reference material for the eZ80 to be more help but I'll definitely tag along.

 

[levi]

Get that appnote that Jeff mentioned further up this page from the zilog site. It mostly seems to be excerpts from the instruction set defintiion that I read, but it's all the ADL stuff in one place, if that's what you specifically want to bone up on.

 

[skeezix]

No time for sitting at desk today (and may be a few days, sadly) .. but when I can't reach the desk, and am stuck in a dark room getting little kids to sleep, I hack away on the old laptop (theres where half my schematic work gets done etc )

I've put a pause on the full 'SkeeBASIC' compiler/tokenizer/VM, as thats some work, and I don't sleep enough lately to be working on a VM and writing a VM interpreter for the eZ80

But a very simple "SkeeBASIC" statemachine and lexer/parser/"compiler" is pretty workable for very rudimentary things. So the currnent state of that is very 'basic' (permit me to over-use the term), but it works. ie: As of today..

You can manually put in a program like this:
LET x = 10
IF x THEN
PRINT "foop"
PRINT "glorp"
ELSE
PRINT "blah"
ENDIF

And can LIST it, and RUN it. Theres a reasonable amount going on under the hood, where it has to parse and compile the text into a bunch of primitives, and it handles it reasonable elegantly for a very quick hack (couple hours total, really)

Its not as general purpose as a real language of course (something like C has a lot of nesting, but being BASIC and a hack, its got a lot of limitations imposed by the language itself. Its ot like you can go "IF IF X" and have the inner-IF's true-clause feed the conditional of the outer-IF etc; the language only allows for a single statement per line, which greatly simplifies implementation considerations. But it does know how to handle atomic elements and sequences (so an IF truth-clause can run a single line or multiple as above say), and it knows how to work with variables; it can work with numebrs and strings.

It doesn't have 'compound statements' yet (stuff like...) 10 + ( 3 * 5 ), or operators at all (like +), and certainly no concept of operator precedence (* is greedier than +) and so on. No function calls at all (in the program, or out to BIOS, etc).

But adding a lot of that (like BIOS calls) is easy.

Next up for SkeeBASIC is to handle parsing a lot better, instance the interpreter (ie: so can run multiple interpreters if need be.. say, for scripting or something); I need to define what the language actually will do (is it just a useless toy, or do I actualyl want to make it remotely useful? It runs on linux as well as Zikzak of course, but I don't anticipate it being useful enough anyone would _want_ to use it. Just a quick hack for lulz, to run on Zikzak..) ... still, what _is_ the language?

You see above no line numbers; thats fine.. my favorite BASIC was "GFA Basic" (on the Atari ST primarily), and it had no line numbers.. just labels and subroutiners; so you could label a section ("main:" say) and then alter do a "GOTO main". Line numbers become sort of stupid at that point (the worst was when you'd do 10, 20, 30, 40 etc, then start to fill in some gaps (10, add 11, 12, 13) and the need to insert some other line.. but can't, gotta go renumbering lines, etc. Annoying as hell.

But I do need to add then, ..
- labels
- GOTO <label>
- GOSUB <label> (which implies RETURN as well, including RETURN with values) for a primitive form of in-language functions

.. and of course some looping (WHILE), which is really just a syntactic sugar on top of GOTO..

Then maybe add some 'funcalls' (Func Calls) out to OS routines; like on linux, open file, print to file, close file, stuff like that.. just for lulz. Cause god help you to use SkeeBASIC for anything useful. That'd be sick.

String manipulation I suppose ("foo"+"bar" -> "foobar"), etc.

Sick sick sick.

I don't know why I do these things

 

[skeezix]

This is some lame code, but its working out okay so far; I'm sure its riddled with bugs and poor assumptions, but for around 3 hours work, its actually working pretty darned well. Had a lull here so added in some basic operator handlers (numeric +, -, /, *, ==, =, !=), and a WHILE loop handler. Theres no real parser going on yet, its all manually constructed elements for the most part, but the bloody thing works:

WHILE X < 10
PRINT "loopydoop"
X = X - 1
ENDWHILE

Code is horribly inefficient (a lot of extra calls and return values, no internal optimization of course). But damn, its pretty cute to have a mini-scripting-language come together so fast. If I added string operations and file operations and some string search/comparisons, it'd almost be vaguely useful

jeff

 

[levi]

If you can make some graphics primitives OS calls, that'd be really sweet. If Python could run on this, I might be able to help out with some python libs to interface with those calls. Dunno how much work it'd be to get Python running on this - I guess you'd need a chunk of OS for it to interface with, but I've seen it build on microcomputer OSes like RISCOS that don't even have threads, so it looks like its build is pretty configurable.

For me, the cool thing about programming in those days was getting a graphic appearing on screen or making a funky tune with only a few lines of code. Python would be a little more boilerplate code than BASIC, but still a way off something like Java.