kelli217

Welcome!

Computer science theory says it can be done. Turing-completeness and given sufficient storage and all that. But theory and practice are not the same thing.

Whenever I think about the YM2151, the first music that pops into my mind is the Marble Madness level 2 music. Which then becomes an earworm...

I'm going to proceed under the impression that your first sentence responds directly to my last sentence. You are probably still correct, but I may not have made it clear that I was talking about completely uncompressed video, or something trivially compressed like Run-Length Encoded or Text Mode Video, where the CPU does not have to do any math to decompress lossy data, but is just pushing pixels or character data. And doing it on this theoretical 3.4 GHz 65C816, with no OS overhead.

So, then, let's drive this discussion in another direction. Assuming that, clock-for-clock, the 65C02 wouldn't be 'competitive,' would a max-speed chip nonetheless still be... 'acceptable' for modern-day tasks? Could you watch a 144p YouTube video? Play a 128kbps MP3? Render a modern web page with scripts and CSS? The question becomes — with what RAM? These things depend on huge datasets being able to be accessed and manipulated, often with SIMD instructions, and there's still only the 64K address space, even with the kind of things that the X16 does via paging. With this kind of sort of primitive MMU style of paging, though, a 65C816 suddenly becomes a much more attractive option. Windows 95 was able to run in the 16MB memory space that an '816 can access, and if the paging system used 4MB pages (scaled proportionally to the size of the X16's ROM pages [or 2MB if you'd prefer it scaled to the RAM page size]), then you've got a sort of supercharged version of the old DOS EMS. You can do some fairly complicated web pages with those kinds of resources. But without a 32-bit data bus and a hardware multiplier at the bare minimum, you're just not going to be able to move enough data fast enough and get enough arithmetic done to play those compressed media files. Uncompressed (or 'trivially' compressed, like RLE or TMV) is no problem. The X16 can do that if you have a fast enough storage interface that you can keep the buffer full. A 3.4GHz '816-based system could push data fast enough to play 4K HD video at 60p if that's all it has to be doing.

Yeah, I believe @Lorin Millsap mentioned something about that limitation of using the high-level libraries quite some time ago.

I think it might be time to drag out this old link that was posted about 12 times to the Facebook community.

If you have an sdcard image set up, and a tool for reading from the image, you can also use the old CMD/LIST method for generating program listings. It's a few more steps than the command line switch, though.

Sorry... I was just thinking of possible alternative ways of running ROM-based code and wedging it into the system that wouldn't require flashing the motherboard ROMs. Sorry if that isn't relevant to a thread about why flashing things into the motherboard ROM is a bad idea.

Not to hijack the thread, but I'd like to ask some clarifying questions, if I may. Will there be an actual version of GEOS that will be made available for the system? If so... Will it just be the deskTop and the desk accessories and preferences apps? The impression that I get is that you guys in the core team are trying to limit the workload, so refactoring geoPaint and geoWrite to work on the X16 seems to be unlikely. And will it continue to default to using the alternative font that looks like University 9 instead of the BSW 9 that's hard-coded into so much of the system? Because that just seems like unnecessary adding to the workload too — bitmap fonts are not copyrightable under US law, and the X16's primary market seems to be the US. So rather than have to go through every part of it that is being ported and adjust anything where the text doesn't fit, why not just stick with the original? Or at least, tweak the modified font so that its horizontal spacing is the same as BSW 9.

Can someone explain some of the details involved in designing an expansion card that maps itself into ROM based on the position of onboard DIP switches? Like... bus arbitration: how you would make sure the card is what gets accessed and not the empty slot in the ROM on the motherboard — or worse, both.

I don't know... I've always considered the border to be a take it or leave it kind of thing. The PET didn't have a border. The TRS-80 Z80-based machines didn't have a border. The Apple II didn't have a border. The Atari 400/800/XL/XE machines didn't have a border. There were some machines that had a border only because the text screen was dark-on-light, like the TRS-80 Color Computer, or the Sinclair ZX series. You couldn't do anything with the border, though, like set its color or anything. So it's really only the TI-99/4A, the VIC-20, the 64, and the 40-column mode in the 128 that had borders that could be set to a different color.

Reminds me of the old days, when you had the official Programmers Reference Guide but there were also tons of third-party books that all had their own way of explaining things.

I've got an old Sony Trinitron CRT monitor around here, a Multiscan 100ES.