Turbo Everdrive 2.4

[TurboXray]

Hey elmer, or anyone else familiar with TED 2.4 (MooZ ?), can you run by the ram mode for me again?

 Can SF2 be run in all ram mode? Is all 4megabytes of ram accessible in some other mapper mode?

 The reason I ask, and this came up in another thread, is that it would be cool to convert a few stages of PCE CD games to run on hucard. Ram mode would definitely allow for that. Gate of Thunder and Force Gear are the two that I had in mind.

[elmer]

Hey elmer, or anyone else familiar with TED 2.4 (MooZ ?), can you run by the ram mode for me again?

Can SF2 be run in all ram mode? Is all 4megabytes of ram accessible in some other mapper mode?

Yes.

The reason I ask, and this came up in another thread, is that it would be cool to convert a few stages of PCE CD games to run on hucard. Ram mode would definitely allow for that. Gate of Thunder and Force Gear are the two that I had in mind.

All the details are here (sadly, not stickied, yet) ...

https://www.pcengine-fx.com/forums/index.php?topic=20120.msg436168#msg436168

Look at the TED_REG_MAP bit settings. 

[elmer]

Hey elmer, or anyone else familiar with TED 2.4 (MooZ ?), can you run by the ram mode for me again?

Can SF2 be run in all ram mode? Is all 4megabytes of ram accessible in some other mapper mode?

OK, trying to be a bit more explicit ...

The TED2 has 8 banks of 512KB.

Bank 4 is always mapped into the low 512KB of HuCard address space.

Any of the the 8 banks can be mapped into the top 512KB of HuCard address space.

"Yes", you can leave the system in RAM mode instead of ROM mode when you enable/use the SF2 mapper at bytes $1FF0-$1FF3, but then you're going to overwrite those bytes when you change the bank.

You only have access to 2.5MB if you use the SF2 mapper.

To access the whole 4MB you've got to write to the TED2's mapping register directly.

Whenever you enable/use the RAM mode, then unlocking and writing the TED2's registers is going to overwrite/corrupt RAM locations $00:$0005, $00:$0006, $00:$0007, and $00:$000A.

It's a fairly good idea to not actually use the bottom 12 or 16 bytes of bank $00.

[TurboXray]

This should be a sticky.

To access the whole 4MB you've got to write to the TED2's mapping register directly.

Whenever you enable/use the RAM mode, then unlocking and writing the TED2's registers is going to overwrite/corrupt RAM locations $00:$0005, $00:$0006, $00:$0007, and $00:$000A.

It's a fairly good idea to not actually use the bottom 12 or 16 bytes of bank $00.

Ohh, that's good to know. For the CD2HUey, I'll need to relocate the bios function entry points there (mostly CDREAD and CDBOOT).

 Kinda offtopic, but I was looking into the bios function list to see if there was any free space, and I came across some functions that aren't covered in the CD manual (the last 5 or so). What is MA_CBASIS???

 EDIT: Have you tested to see if TED 2.x loads 4megabyte rom data into the all 8 banks? Or does it stop at the first 5 (ala SF2)?

[elmer]

This should be a sticky.

Or you could just modify your 1st post in the "Graphic, Sound, & Coding Tips / Tricks / Effects / Etc." thread to be a "links" post to other threads with interesting and useful information. 

Whenever you enable/use the RAM mode, then unlocking and writing the TED2's registers is going to overwrite/corrupt RAM locations $00:$0005, $00:$0006, $00:$0007, and $00:$000A.

It's a fairly good idea to not actually use the bottom 12 or 16 bytes of bank $00.

Ohh, that's good to know. For the CD2HUey, I'll need to relocate the bios function entry points there (mostly CDREAD and CDBOOT).

Yep, that's the problem that I had with the TED2 System Card hack.

I ended up keeping copies of the first and last 16 bytes of bank $00 and then copying them back into place after they'd been corrupted by having to write to the TED2 registers while bank $00 was in RAM mode.

You can actually use the SF2 mapper to access the top 2MB of RAM space ... you've just got to use the TED2's registers to decide which 2MB region you want the SF2 mapping to use, and then understand that the bottom 512KB of HuCard space is always the TED2's bank 4.

Have you tested to see if TED 2.x loads 4megabyte rom data into the all 8 banks? Or does it stop at the first 5 (ala SF2)?

I've not tested it, but I imagine that it only loads 2.5MB maximum.

Krikzz doesn't seem to bother too much with thoughts of theoretical concerns of what us homebrew folks might do in the future with the extra memory.

BTW, Krikzz is using some of that extra 1.5MB of space for the TED2's OS.

[NecroPhile]

They're both stickied now.  I don't know if it'd make sense or not (this stuff is way over my head), but I can merge 'em if you want.

[elmer]

They're both stickied now.  I don't know if it'd make sense or not (this stuff is way over my head), but I can merge 'em if you want.

Thanks! 

From my POV, I don't think that we need this thread to be stickied, just the "TED2 Programming Notes" thread.

That's the one with the core information, and I'll be updating that thread when I finally get the time to get back to figuring out how to access the SD Card.

Best to check with Bonknuts, though.

[TurboXray]

One thread is fine.

[MooZ]

I only have a v1.
I can't imagine how much unrolled self modifying code I can put into 512KB of RAM...

[elmer]

I only have a v1.
I can't imagine how much unrolled self modifying code I can put into 512KB of RAM...

I really can't recommend the TED v2 highly enough, especially with the USB link because you're a programmer.

Having 1MB/2.5MB/4MB of RAM (depending upon how you want to set it up) is a really, really nice. 

The only reason to limit stuff to 512KB would be in order to run on a semi-cheap-to-make 512KB ROM + 512KB RAM HuCard that nobody has made yet.

Even then ... I'd honestly prefer a simpler and even cheaper 1MB RAM card (using the Duo's built-in BIOS), or just paying the little bit extra for the TED v2.

[OldMan]

The only reason to limit stuff to 512KB would be in order to run on a semi-cheap-to-make 512KB ROM + 512KB RAM HuCard that nobody has made yet.

I thought you were worried about fracturing the market for flash cards. Worried that games would have to have code to deal with various mappings, etc.

Did you want one? It works like a standard HuCard, except banks $40-$67 are available. They only have a memory test on them, so you would need an eeprom programmer and adapter to re-program it. I'm working on pulling together bios and some extra stuff, but there's no hurry, since there is no demand.

I've been thinking about what tom said, though. I may do one with the RAM in the $8000 area, just to see if I can get a 8Mb rom and 512k Ram to work.

[elmer]

The only reason to limit stuff to 512KB would be in order to run on a semi-cheap-to-make 512KB ROM + 512KB RAM HuCard that nobody has made yet.

I thought you were worried about fracturing the market for flash cards. Worried that games would have to have code to deal with various mappings, etc.

Definitely ... when it comes to translations, which was the primary driver for this whole "I need more memory" discussion that we've been having over the last year.

Limiting things to 512KB certainly makes the most sense for translations that just need a little extra space and want to work on pretty-much-any expanded-memory card that's been released, or is ever likely to be released.

When it comes to homebrew, then I think that things are a bit more open to each individual developer's desires.

Did you want one? It works like a standard HuCard, except banks $40-$67 are available. They only have a memory test on them, so you would need an eeprom programmer and adapter to re-program it.

Thanks for the offer, I really appreciate it, but I'm afraid that I really can't quite figure out what I'd actually use one for.

I'm working on pulling together bios and some extra stuff, but there's no hurry, since there is no demand.

This is my problem with a ROM/RAM card when we talk about it as a new System Card "standard".

It's software that sells things, not the hardware.

I already have 2 alternatives for doing a CD game that gives me lots of memory ... the Arcade Card, or the TED v2.

I have difficulty imagining a CD project that I'd be interested in, where the additional cost of a new System Card with only 512KB on it would make any sense.

The TED v2 makes sense for folks to buy ... it does a lot of stuff.

The Arcade Card is something that a lot of folks already have.

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

*************

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!

If I'm shipping something on ROM, then I want as much space as possible for data, and don't really need lots of RAM.

Something larger than the 8KB in the base PCE console would be nice, sure, but 64KB or 128KB would be plenty if I just need space to decompress stuff from the HuCard.

At that point, I'd probably be tempted to rely on using the 64KB of memory in the CD system and leave the 1MB of HuCard space entirely for ROM.

It would require folks to have a CD system, but that's not exactly a show-stopper these days.

OTOH, putting a small amount of RAM in upper memory isn't that difficult (except for fitting it on the HuCard) if you don't mind charging folks for it.

Then again, these are just my thoughts and perspectives based upon the kind of game projects that would interest me to do.

Perhaps other folks have a different perspective.

I've been thinking about what tom said, though. I may do one with the RAM in the $8000 area, just to see if I can get a 8Mb rom and 512k Ram to work.

Do you mean the bank $80 area???

If so, then you definitely can't use that, because you'd conflict with the 64KB of memory in the CD interface.

But banks $a0-$df are free AFAIK if you want to put some RAM in the upper area.

[OldMan]

Thanks for the offer, I really appreciate it, but I'm afraid that I really can't quite figure out what I'd actually use one for.

Funny, that's kind of my problem.too. I don't think i've ever used all of even the stock 8K of ram.

This is my problem with a ROM/RAM card when we talk about it as a new System Card "standard".

I don't think of it as a new 'standard'. I doubt that many would be produced.
Where I do think it would be useful is for an in-expensive debugging tool.

At that point, I'd probably be tempted to rely on using the 64KB of memory in the CD system and leave the 1MB of HuCard space entirely for ROM.

I can see that. But then you are limited to CD systems (which isn't a big deal to most of us).

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

Ok. But it's been fun to play with, And see how cheaply it could be done. (Its about $20 in parts)

Do you mean the bank $80 area???

Actually, I meant the $80000 area, as in upper half of the address space. I still think I could fit 512k ram up there cheaply. And no, not at the $80 bank. Maybe the  $A0-$D0 bank range. Right in the middle. (Physical addresses $a0000-$Cffff, I think)

I'll go back to working on the video converter now. With toms quick cd read routines and 512K Ram for bufferring, I might just get sewer-shark working yet

[TurboXray]

I already have 2 alternatives for doing a CD game that gives me lots of memory ... the Arcade Card, or the TED v2.

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. I opted for the Duo card replacement, simply because of less hardware in the case that something might go out, but there's still a lot of hardware on that card as well. It's be really nice if the next TED, assuming there is one, emulates the AC regs.

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.

[TurboXray]

I'll go back to working on the video converter now. With toms quick cd read routines and 512K Ram for bufferring, I might just get sewer-shark working yet

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

[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.

[TurboXray]

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 ;)

[OldMan]

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

[TurboXray]

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.

[OldMan]

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)

[TurboXray]

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....

[TurboXray]

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.

[TurboXray]

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.