flashjazzcat

Can we make custom editor templates under WUDSN? I've tried to edit templates but there's no context listed for the A8 editors. Would be nice to have shorthand for lines of dashes in comments, etc.

The relocation technique described in the docs is interesting (assembling at two different addresses and building a table of the differences), and is something I saw mentioned on another forum the other day when I was trawling the Net on the subject. I'm reminded now of Multi-Mouse's main limitation: the fact (IIRC) it polls the input device in a continuous, closed loop until the button is either pressed or released. At the time I think I wanted to use it for a drawing program, but there was no way to use the driver for "rubber-band" drawing, etc, since the CPU was sampling the input flat-out. Of course this was one sure-fire way of ensuring sufficiently high sampling rates and thus smooth pointer movement without any software mouse acceleration. Really interesting to see this again, though: nice work.

Shouldn't take as long as the initial estimate, and it's going OK so far. I've actually been subject to yet another distraction in the form of the multitasking kernel I've started writing. It'll actually be useful to get this working at this stage: it'll remove the need to code up any cart jump tables because the kernel facilitates inter-process messaging using the 6502 BRK instruction. I've got the scheduler interrupt running in the test build already and the core kernel's about half done, pending testing and debugging. The trickiest bit is probably the message queue, which is a linked list to allow only those messages dispatched to a particular addressee to be pulled out of it. This approach appears to follow the SymbOS model but I'm waiting for Prodatron to confirm this. In any case, the kernel is one of the more fascinating parts of the project. Yes Kyle I know of it, and it may even have been mentioned earlier in this thread. Thanks though. I imagine the context switching overheads in that utility were pretty large, since it would have to handle all the hardware registers, the entirety of page zero, the whole stack, all of main RAM, etc. Fortunately the GUI only has to swap out a tiny bit of page zero and any section of the segmented stack which is currently cached. The thorny issue of binary relocation format still weighs on my mind...

I remember typing this in back in the day from listings in New Atari User. Very nostalgic.

Thanks! I'm still a bit spooked about that 4MHz crystal / PAL issue mentioned in the review, but there's very little information on the PRC to be found.

The different 65816 emulation speeds are great. This has enabled me to get rid of the cycle counting in my mouse renderer and make something which works at any CPU speed. Thanks!

The source code is pretty interesting. I agree that all the C implementations I tried on the A8 back in the day (namely Deep Blue C, ACE C, and CC65) had severe limitations, but by far my best experience ended up being with the last one: the old A8 version of CC65. Once the libraries were trimmed down somewhat (I rewrote most of what I needed in assembly language), the environment was quite suitable for developing small to medium sized projects. Persistent drawbacks included the enormous size of the compiler (40KB, which at least seemed huge in the days of floppy disks), and the terribly slow I/O when compiling (especially under SpartaDOS X, since it wasn't using the mini buffers for single-byte get/put when the cart was disabled, as it had to be to run CC65). Recompiling the compiler itself with a rewritten library and more efficient I/O routines would have made it quite usable, IMO. I believe the modern (cross-compiler) version of CC65 uses much the same stack model as the old A8 version (using indirect (ZP),Y addressing), and this is something which causes performance problems with CC65 applications today. David A Wheeler touches on the stack implementation problems in his excellent article 6502 Language Implementation Approaches. IIRC, somewhere he advocates using a fixed 256 entry stack (the location would be decided when the linker was fixing up the addresses) using 6502 X register addressing. This could be interleaved, providing reasonably efficient stack access and provision for up to 32-bit integers with a 1KB stack. I can see why P-Code or variations thereof was used in the DBC and ACE C compilers from the perspective of code size. I haven't used the modern incarnation of CC65, but I remember the old A8 version spewing out a lot of stack manipulation code for every function call. The calls to popax / pushax were also very slow.

No - just hadn't wired up the harness yet. That's not my machine and it's the only photo I took which shows the ribbon cables.

This is V2, Peter, but should give you an idea of the cable orientation nevertheless:

I've known a few to whom it applies.

Although the printer works fine with my P:R: Connection, I still can't get ICE-T to work with it via the Lantronix MSS-100. Starting to think the PRC itself has an issue, then I discovered this review: http://www.page6.org/archive/issue_30/page_74.htm My PRC has a 4.000 MHz crystal. Could that perhaps be causing problems with RS232 (on PAL machines)?

Correct, that's exactly what it means. I'd forgotten he also put his moniker on them.

V2 has the picture of a wheelie-bin on the back with a cross through it.

Crikey... nice surprise. Was just going to set up a second Pokey interrupt to test scheduling when I discovered I'd already set one up (at 50Hz) with quite a long dummy delay in it. Turning this off speeded up rendering yet further, and the fact is the scheduler won't usually be doing that much work when most processes are in a "not ready" state.

I wouldn't want to swap out whole applications since this would require storage access in the interrupt context (although it would be just fine for simple task switching), but there's no reason that indirectly accessed extended RAM can't be paged out to disk. RAM allocated from the extended pool is never directly addressed by applications anyway, so if it's not around when the application requests a piece of it, we can just pull it in from disk.

These are just awesome - thanks so much.

Tebe is responsible for any enhancements to the way MADS produces relocatable files. I sent him a PM three weeks ago regarding the single block limitation, etc. Presumably he's too busy.

See if you can get an LG M1921a or similar. Even if it doesn't have a SCART (and most do - and SCART's generally the best bet in Europe), the VGA input on these monitors syncs down to 15KHz.

Not premature at all: I already found myself copying and pasting common setup routines which need to be accessed in different banks. This seems to me a sensible way to proceed, especially when we have 40KB of space still to fill in the smallest target platform (U1MB). Sometimes a big code-inventorying phase like this is a really good time to take stock of the positioning of various routines. Heh - if anyone writes a tool like the one you describe, I'm using it.

Oh no - nothing will remain embedded in the ROM apart from a few small tables. Everything will be pulled in from external resources, which will mean you can change the system font, assign your own icons (from a very considerably sized selection), etc. I might even put stuff like dithered scrollbar patterns and closer/fuller buttons in resources as well, so the system can be skinnable to a certain extent. The shell will also be an application, so if someone wants to write a "Symcommander" to use instead of the default file manager, that'll be possible too without changing the ROM. I'll very shortly have to face the decision about which of MADS' two relocatable binary formats to use, too: SDX or proprietary. Proprietary would be better (since it allows lo/hi byte relocation, and has a slightly simpler layout), but it doesn't currently support multiple RELOC blocks in the same file, which I'll need (for drivers which - for example - install part of themselves in low conventional RAM and another part in extended memory), nor different RELOC segment types (for example - MAIN and EXT). The SDX format supports both of these, but not lo/hi byte relocation (which can be easily coded around, of course). The MADS format has a few niceties like long external symbol names, but I'll have to go with whatever's best when the time comes.

Started conversion to ROM today, and this is probably going to be the most critical part of the project (i.e. the part when I'll keep wanting to give up because it's such a bloody nightmare). Some stats: there's about 24KB of code at the moment (not including fonts, icons, data, tables, etc: the XEX is currently 39KB with wallpaper and everything else embedded inline), and by far the largest "module" (which will fit nicely into an 8KB ROM bank) is the graphics segment - i.e. everything which writes directly to the screen. The next biggest module is the window manager (which is 5KB but will get its own bank), and then the code size drops off pretty sharply after that. I figured the best way to start this gargantuan task was to place a ".LOCAL" wrapper around the entire graphics source file, so that instead of JSR ROUTINE (in any other bank), JSR GFX.ROUTINE would be required. When editing the calls, I'm also changing JSR to LJSR (the latter being the inter-bank JSR macro call), so we now get LJSR GFX.ROUTINE. That's nicely self-documenting, in as much as it clearly shows what's an external call and what's not. This threw out 117 assembly errors which I had to pick through (most of which were calls which needed amending as described above, obviously), and I was reminded of one thing I'd forgotten: that any kind of jump table will no longer work unless the target routines are in the same bank as the table, so they'll have to be redesigned too. Of course I'm also moving all the variable space down into low RAM, which will obviously need initialising by the cartridge code, and encountering (as I go) some poor decisions regarding local variable space tacked onto the end of LOCAL ranges (which obviously won't work in ROM); these have to be renamed and moved. There's much scope for bug-creation here. So - rinse and repeat on another dozen source files (albeit smaller ones), until the thing works with the LOCAL wrappers in place, at least. Then switch the assembler to BIN mode, add padding to the banks, relocate the (test) application to low RAM from the init bank of the cart, make sure the interrupt handlers and everything else which needs to be is out of the way of banked ROM... and no doubt watch the whole thing fail to work for a number of weeks. Then - when stuff's just about working - I'll have to look out for any performance hits caused by slow inter-bank calls in critical areas, and move the offending code to a different bank. I'm pretty sure it'll be snowing while this goes on... at least if we have a long, arduous winter. And when that's all done, we can pick up where we left off adding to the functionality, designing the API, etc, etc.

And multiple .RELOC blocks of user-definable types (main, extended, etc)???

Yeah - I completely agree Joey.

I quite like the look of LZ4 and am sure to find a use for it somewhere in this project, given GUIs tend to be quite data-heavy.

Thanks for posting that: a great read.