Turbo Everdrive 2.4

[elmer]

I like the arcade card, but the failure rate on those things makes me a bit more reserved about using it. I've already had one fail (never had a hucard rom fail). I know of five other people/instances were the cards were bad.

Was that a PRO or a DUO that failed?

I've got a few Arcade Card DUOs and 1 Arcade Card PRO, and luckily haven't had any problems, yet.

I wonder if they're just more sensitive to static electricity than regular HuCards?

Conversely, looking at things from a HuCard perspective, where I don't have a large CD of stuff to load, then I really don't need that much RAM. I wouldn't know what to do with it!

I do! Copy over graphics into a buffer for levels.. as embedded opcodes for super fast VRAM updating.

Hahaha, so ... you'd dramatically bump up the cost and complexity of the HuCard, as opposed to just including a larger ROM chip? 

BITD, that might have been seen as a "questionable" use of resources! 

Even for that use, it doesn't seem like you'd need much RAM if you've only got a 512KB or 1MB ROM.

[Bonknuts]

Well, I have some pretty drastic style demos that abuse ST1/ST2 embedding (nothing public), so it bloats the rom something awful and doesn't allow for compression. Compression + ram for embedding graphics is a great combination. Might lead to load times for the start of a stage, but that's livable

[TheOldMan]

I do! Copy over graphics into a buffer for levels.. as embedded opcodes for super fast VRAM updating.

Just out of curiosity, could you decompress graphics into a spare 8K page as ST1/ST2 opcode format for updating? Then you would get the best of both worlds; room for more gfx, and quick update times. Though there would be a one-time decompression penalty...

It'd probably be easier to isolate/rip the huvideo player for that kind of thing.. which I don't have :/

The player part is pretty simple, apart from buffer management. I've got 1/4 screen 12fps working now, with slightly garbled sound and occasional pauses when it loads using the stock CD routines. I'm pretty sure with 2 128K buffers, it would be smoother (most of the time). And if I ever get around to using the fast-read cd routines, I figure 15fps at 1/4 screen would be doable.

But what I was really talking about is the win version avi->pce converter. Gotta have some kind of video to test with

[Bonknuts]

I do! Copy over graphics into a buffer for levels.. as embedded opcodes for super fast VRAM updating.

Just out of curiosity, could you decompress graphics into a spare 8K page as ST1/ST2 opcode format for updating? Then you would get the best of both worlds; room for more gfx, and quick update times. Though there would be a one-time decompression penalty...

Yup. Though I was thinking not only stuff like sprites, but large amounts of dynamic tiles too (with 512k).

It'd probably be easier to isolate/rip the huvideo player for that kind of thing.. which I don't have :/

The player part is pretty simple, apart from buffer management. I've got 1/4 screen 12fps working now, with slightly garbled sound and occasional pauses when it loads using the stock CD routines. I'm pretty sure with 2 128K buffers, it would be smoother (most of the time). And if I ever get around to using the fast-read cd routines, I figure 15fps at 1/4 screen would be doable.

But what I was really talking about is the win version avi->pce converter. Gotta have some kind of video to test with

 I did some avi to pce converter, but not avi directly. I outputted to a sequence of BMP files, and had my utility read them in sequence order. I was impatient not wanting to mess around with an avi lib. I only did 16 color frames. If you manage to do more than 16 color frames, you should share it

 Also! Don't discount the PCE H-blur technique when doing video. It makes checkered board, or vertical line dithering, look really nice at 30fps blend (100% solid on a CRT). There's actually a SegaCD game that does it, but alternates the horizontal lines (same idea, different direction) - Mortal Kombat CD. Nice technique, but hblur is better.

[TailChao]

I'm just having trouble seeing where a 512KB/512KB System Card fits in, or would actually be cheap enough to sell to folks.

Of course, the elephant in the room from when we discussed this over a year ago is still loitering by the water fountain -

Duplicating NEC / Hudson's firmware is a big legal grey area. The TED v2 puts that responsibility on the user and the CD Stupid Cards just happened to have the bits on flash arrange themselves in a somewhat convenient order.

[TheOldMan]

Yup. Though I was thinking not only stuff like sprites, but large amounts of dynamic tiles too (with 512k).

Okay, let me get this straight, at least in my head.
You run the graphics through a compressor, and add that file to the cd (not necessarily as a seperate track). Then you load 1 page (8K) of graphics (compressed) from cd, and de-compress them. As you decompress (to other page(s) ), you add ST1/ST2 opcoded, and an rts for each gfx you want to load. Then you can map the page in and run the routine whenever you need the gfx loaded.

That, sir, is a masterful idea.

I did some avi to pce converter, but not avi directly. I outputted to a sequence of BMP files, and had my utility read them in sequence order. I was impatient not wanting to mess around with an avi lib. I only did 16 color frames. If you manage to do more than 16 color frames, you should share it

I had some code from another project that did most of the avi container handling. So the program ended up allocating 2 huge buffers for the avi video data. Then it read in a frame of data, and converted it to pce format, building the palettes as it it went. (It packed as many colors in a palette as it could, checking for colors already there, etc, etc... Once it had a frame of pce data, it compared it to the last frame in 8x8 tiles on a row by row basis,  keeping a bitmap of which tiles needed updated. That was optimization 1 - only loading what was needed to the vdce. Using the same bitmap, it would fix any palettes (both the BAT entry and the color table) - but ususally that got skipped (video doesn't change palettes much except on cuts/fades. So it would sort of handle 256 color images, though it bombed out if a tile had more than 16 colors
The big problem was converting the audio, since that's ineterleaved with the video - in various sized chunks Didn't know about the clipping problem for adpcm then, so the sound was kind of scratchy.
Yeah, someday I'll add a better color converter (ie, nearest neighbor color changes for tiles with more than 16 colors) and re-write the audio converter.

I'd have to find a place to host it, beforeI released anything. And the code is, (being polite here) a big mess

Duplicating NEC / Hudson's firmware is a big legal grey area.

What if I just keep the general format of the functions, and replace parts with code from somewhere else? I'd eventually like to replace the cd routines with something faster; I'd also like to extend the bios with a few extra 'libraries' of code (kind of like how the psg player and math routines have their own pages)

[Bonknuts]

What are the legal bits about binary code? Does it fall under copyright? Or something else?

[spenoza]

What are the legal bits about binary code? Does it fall under copyright? Or something else?

Compiled or not falls under copyright.
If you can reverse-engineer it, however....

[Bonknuts]

So what if you disassembled it, and then reassembled it - resulting in a very different binary layout?

[elmer]

So what if you disassembled it, and then reassembled it - resulting in a very different binary layout?

Doesn't count ... that's a mechanical transformation, it's still the same sequence of instructions that someone else wrote.

And "no", just moving around the order of the functions won't change it, either.

It's still legally copyrighted.

"Reverse engineering" has to be "clean-roomed" in order to be legal.

That means that one team reverse-engineers the code to find out what it's doing, and then writes up a clean specification document that details the interfaces and the general algorithms (i.e. the meaning of the hardware bits, and the access restrictions and flow chart for setting them).

Then a totally separate team writes compatible code based upon those specifications without ever have seen the original code.

Take a look at the history of the first successful clones of IBM's PC BIOS, and the expensive lawsuits.

[Bonknuts]

Well... at least that's permissible.

[spenoza]

Elmer has it. Though, keep in mind that clean-room re-implementation is only for copyrighted stuff like code (BIOS, etc...). For implementing stuff that's not code (like hardware emulation), you don't have to go clean room since copyright isn't the issue. Doesn't help here, though.