TheMole

So, I seem to have lost or misplaced my consoles during one of my moves in the past couple of years. I just spent 3 hours digging around in old cardboard boxes in a musty basement and they are nowhere to be found (I did find my C64 and my Atari ST, which I completely forgot I had ). I found my twe PEB's, my carts and other goodies (although I can't imagine the floppies have survived the damp storage space), but no consoles or power supplies. Anyway, I just started playing around with coding for the F18A, and would need real hardware to test some things on (js99er.net is great, but my computer isn't fast enough to run the GPU emulation at full speed). Does anyone on here who's in Europe have a console and power supply that they are willing to part with for a reasonable price? I'm not looking for a collector-quality item, just something that works. I'm willing to spend extra for a beige model with working keyboard though!

Certainly, but that's way beyond my skillset. I'm trying to coerce Insomnia's port to create binaries that can run on the GPU. So far no luck yet, but I'm sure it should be possible (gcc will never emit LIMI or CRU instructions itself, and a cursory overview of assembly generated for any of my projects reveals no BLWP, STWP, etc... instructions). I'm currently trying to figure out the right crt0 setup and linking requirements.

This are instructions related to the workspace pointer, XOP and X, right?

I wonder if we can let gcc output code that can run on the GPU?

That is insane. Looks as if it might be the most playable 8-bit SFII port I've ever seen. Also, nice color pallette reduction they've used there... Compare that to that other z80 machine with 9918a heritage: https://youtu.be/5H7bR7wzBo4?t=2m2s Sure, it scrolls, but the stages looks much more simplified and the animation seems to be missing a couple of frames. Not to mention the horrible slowdown...

That's roughly what I thought. Now, for a trackball, that's ok, since it's basically an "infinite range" device. A mouse however, would have to be picked up and replaced on the desk quite often to make up for the lack of speed and acceleration typically afforded by real mouse driven applications. To me, that would kill any benefit a mouse might have. So, while it might be adequate for a trackball, we can't assume that this will be equally true for a mouse.

I've been wondering for a while... Would it be feasible, if I have hosted an .rpk and/or .dsk file somewhere, to allow me to create a link to js99er.net that automatically fetches and loads that cartridge/disk? Maybe by extending the Google Drive support that's already in there? Or perhaps a way to add files to a js99er.net-hosted repository directly, and allow loading some of those files automatically? Once we have that, I would imagine we can ask Albert to allow embedding of a js99er.net instance in forum posts, so game development threads can come with an embedded emulator (kinda like what sometimes99er sometimes does with his Flash demos).

http://codehackcreate.com/store#!/F18A-V1-6-Video-Board/p/14022176/category=0

Hmmm... for those of you who've tried it, how well does a mouse work with programs written for joystick control, that don't take acceleration into account? I can hardly see that being a very usable solution?

Cool! Sine-wave "water", or parallax scrolling effect?

Yeah, the SMS VDP is an elegant extension to the 9918a, but it doesn't have anywhere the features the F18A has (even ignoring the GPU), and like you said: one page scrolling can be approximated in a number of ways so I'm not too worried about that. The scroll lock registers are fine as well, since for most of my scenario's you can just as easily use the scanline interrupt to set the scrolling registers after the locked area has been drawn to screen... (well, if it's a horizontal locked area at least)

That's perfectly achievable with one page as well (in fact, this is how the master system does it). Consider the following pseudo code: nr_columns = 32; current_column = 30; for (position = 0; position < map_width; position++) { // After every 8 pixels of scrolling, we need to start updating the next column if (!(position % ) current_column = (current_column + 1) % nr_columns; // current_column wraps at 32 columns tiletable[current_column, ((position % * 3) ] = new_tile_1; tiletable[current_column, ((position % * 3) + 1] = new_tile_2; tiletable[current_column, ((position % * 3) + 2] = new_tile_3; update_scroll_register_pixel(position % ; update_scroll_register_char(current_column); } Basically, the column that is being updated each frame is the hidden one, and the first column that is rendered on the left-hand side of the screen is the column after the hidden one. With regards to non-scrolling regions, I seem the remember the F18A had scroll lock registers, that you could use to keep certain screen areas from scrolling, but I can't seem to find those back in the sheet? I'm probably misremembering though...

That's a shame, it would make scrolling much cheaper as far as VRAM is concerned. A better workaround might be the bitmap layer, that would only eat up 192 bytes of VRAM (in 1bpp color mode). Instead of a second tile layer or a second page (both of which need 726 bytes at the least). *edit* just noticed that the BML doesn't have a 1bpp mode, but at 384 bytes it's still less than a full name table. But sprites would be even better, you'd need 48 bytes in the sprite attribute table (12 16x16 sprites) and worst case scenario 96 bytes (in ECM3) to define the needed 16x16 pattern in the sprite generator table, totalling 144 bytes. Of course, you'd be left with only 20 sprites then, but depending on the game that might not be a problem. Not that bad really, now that I think of it

Very nice! Well, if you insist . When scrolling horizontally using just one page, does the first/last visible column have to visibly wrap on the screen edges, or is a scroll page one column wider (and/or row higher) than what is visible on the screen?

That is all kinds of awesome!

I'm with sometimes99er, you should probably try to align your hex grid on character boundaries. Then, you can presumably store the patterns in VRAM and redraw by simply updating the nametable. You would be able to do nice character-based scrolling, hex-based scrolling or zelda-style screen scrolling. I wanted to see what it would look like, and granted it isn't as dense and elegant as your original, but it would still be usable enough and would probably be smoother/nicer to play. You'd also neatly avoid any color clash with your tiles .

Are you saying that in XB3, you can treat the AMS as one big block of memory for code, variables, etc... ? That would be very impressive! I'm sure that will have required extensive changes to the interpreter and garbage collector (and any other parts of the system that handle memory allocation).

Excellent post Greg. I just want to add that for me, the feature set and programing model of the F18A is much nicer than that of the v99x8's and I for one am glad that he chose to add the ECM modes, scrolling registers, bitmap layer and multiple graphics planes instead of shooting for v9938 compatibility (a chip which doesn't support horizontal scrolling needed for games like Alex Kidd without introducing jitter and artefacts). Matthew might be designing these features for himself, but let there be no doubt that he has created a highly desirable product and has a real audience that he is serving with this that does not want to see this project move in the direction of becoming a v9938 clone.

I get what you're saying Lee, but to my mind the effort to add more RAM to the F18A or create an FPGA-based v99x8 hardware design from scratch is probably a couple of orders of magnitude more daunting than modifying a piece of software, so modifying Funnelweb is probably the path of least resistance.

Does the SAMS use CRU for bankswitching, or magic memory locations?

If there's a SAMS, or other fast and large memory expansion connected to the system? Absolutely! And it'd be faster than anything that uses VRAM for the same purpose. You have to remember that writing to/reading from VRAM is incredibly slow, and even the simplest edits will require reading a chunk of text from the buffer in VRAM, copying it to RAM, making the modification in RAM and sending it back over to the VDP; if you do that in CPU RAM, you'd at least be skipping the reading from VDP and copying it to RAM part. So, in short, yes an 80-column word processor would work better and faster when using the SAMS than when using VRAM as its buffer. We in the TI community have historically had to abuse VRAM as some sort of general purpose memory, which tends to make some of us forget that this is not what it was designed for and that in essence it's a horrible, horrible hack to offset the paltry 256 bytes of memory that the system ships with. Unless there's nothing else available, you should always avoid using VRAM as general purpose CPU memory: it is meant to support the VDP's functions and that's what you should use it for. If available, RAM connected to the CPU bus will always be heaps and bounds faster and more flexible than VRAM, for every single non-display related function. Asking for more VRAM on the F18A "so you can store text buffers in it" is like asking for a pick-up truck so you can store your lawnmower in it: yes it'll do the job, but you would probably be better off getting a garden shed (or a SAMS) instead...

This, a thousand times this!

I'd be most interested in this as well. It sounds like it could be used as a high res (480x240) character graphics mode?

I just peed a little... that is a thing of beauty, and as an owner of a couple of (for me now bland looking) black-and-silver consoles I would give my left arm nut for a setup like this...

Wow, Sam's Journey looks incredibly nice for being a C64 game. Even better than Mayham in Monsterland, which makes the Gianna Sisters look like crap in comparison. That's no where near possible on a standard ti994a, but one with an F18A should be able to pull that off just fine. On Alex Kidd... I've been slacking and haven't worked on that for a couple of months now... I hit a wall when I ran out of memory and couldn't find a compression/decompression scheme that is fast enough for the smooth scrolling. I could do an F18A version first, since that would be a lot easier, but I want to make something for the stock console and let the F18A shine through hardware optimizations and additions. I haven't forsaken the project though, I will get back to it... someday, hopefully someday soon