|
Post by dshadoff on Nov 30, 2019 16:36:13 GMT
In the meantime ... having 4MB of RAM, and a fast way of loading data from an xxGB-sized SD card currently exists, if there were only active developers that wished to use those capabilities. How can we currently load data from the SDCard ? I wasn't aware of this functionality... It seems reasonable that a motivated person might want to hack the System card to read the SDCard for data instead of the CDROM, for multiple-iteration development... ...Or even to add new functions we've never seen before, like huge HuVideo-like output from a HuCard game...
|
|
|
Post by elmer on Dec 1, 2019 1:59:52 GMT
How can we currently load data from the SDCard ? I wasn't aware of this functionality... Well, I *thought* that the old beta version of TEOS that I sent you was functional, and that you were able to load HuCard images from SD card, proving that the functionality exists. Sure, I'm still not finished with TEOS yet, but I don't suppose that there's any harm in finally uploading some of the library code to github ... it seems pretty stable at this point. Unless you've already installed the USB transfer functionality in your TED2, then I suspect that you're not actually going to find much fun in experimenting with any of the source code that I release. It seems reasonable that a motivated person might want to hack the System card to read the SDCard for data instead of the CDROM, for multiple-iteration development... Yes, I have the same thing in mind ... but I just want to ditch the old System Card code entirely, IMHO there's very little in there worth having these days. ...Or even to add new functions we've never seen before, like huge HuVideo-like output from a HuCard game... Yep, development that is specifically targeted at the TED2 could do some nice things! A quick test of loading the 2.5 Mbyte Street Fighter II HuCard shows that I'm able to read from the SD card at 900KB/second, which isn't too shabby.
|
|
|
Post by turboxray on Dec 1, 2019 4:17:59 GMT
I got my TeD today. Is writing to the card part of the lib?
|
|
|
Post by dshadoff on Dec 1, 2019 5:02:25 GMT
How can we currently load data from the SDCard ? I wasn't aware of this functionality... Well, I *thought* that the old beta version of TEOS that I sent you was functional, and that you were able to load HuCard images from SD card, proving that the functionality exists. Sure, I'm still not finished with TEOS yet, but I don't suppose that there's any harm in finally uploading some of the library code to github ... it seems pretty stable at this point. Unless you've already installed the USB transfer functionality in your TED2, then I suspect that you're not actually going to find much fun in experimenting with any of the source code that I release. Sorry, I read the original message as stating that an API of sorts had already been published and was available - or perhaps hidden hooks to functions in the original TEOS. Although I had begun a disassembly of the original OS of the TE, it became opaque really quickly and I don't think I found the SDCard functions. I'm looking forward to your release ! ...Or even to add new functions we've never seen before, like huge HuVideo-like output from a HuCard game... Yep, development that is specifically targeted at the TED2 could do some nice things! A quick test of loading the 2.5 Mbyte Street Fighter II HuCard shows that I'm able to read from the SD card at 900KB/second, which isn't too shabby. Indeed, not too shabby at all ! And multi-gigabytes of storage too ! But I'm wondering about impacts to sound... CD audio wouldn't be possible this way, and I'm not sure how SDCard loads would affect PSG players driven by interrupts... I got my TeD today. Is writing to the card part of the lib? Actually, writing would be more difficult than reading in the general case: as a file is being extended, one can't assume that the next block of SDCard memory will be available, so extents may need to be allocated, and may be discontiguous. This can complicate things a lot. I'm not sure whether this is planned, but I had discussed the possibility of overwriting an existing file's contents (which should be straightforward).
|
|
|
Post by elmer on Dec 1, 2019 5:05:18 GMT
I got my TeD today. Is writing to the card part of the lib? Yes, partially. You can write to SD card sectors, which will probably screw up your FAT32 file system ... and you can overwrite the data in existing files on the FAT32 partition, which is what TEOS does to save BRAM and MB128 data to the SD card. Just know that there is no accelerated-write hardware in the TED2, so writing is a *lot* slower than reading.
|
|
|
Post by turboxray on Dec 2, 2019 19:31:34 GMT
Yeah, I figured having a file already on the card to modify would be easiest instead of finding a block of sectors and modifying the file system. But that's great news! I wanted to make a tracker on the PCE that could save to a file on the card, but also read in files.
Update: I converted the color matching algorithm to use CIE LAB. I've only implemented the DE76 distance algorithm for now. While it works much better than RGB distance, it does have a few quirks for dark colors. I'll try out DE2000 and see how that does (it's a hell of a lot more complex, but should be fine for this app). I added more functionality for 'fixing' errors on the destination image; taking source tile and seeing a preview against an existing palette and then allowing an overwrite of the same tile in the PCE image. I added a merge two palettes option since I now have CIE LAB support. It's not fully optimal (doesn't prioritize pixel coverage per color), but it's impressive as is. Same for colors in a palette; colors can be copied and then removed to free up a color slot.
I'm pretty happy with the state of it right now. I might release a beta in the next couple weeks. I need to improve the 'scoring' system for 'out of bounds' tiles (final phase; tile doesn't belong to the top 16 palettes and/or has more than 16 colors). I also plan to start work on functions that allow editing the source image, and also be able to write back PCE converted tiles to the source image (for viewing tile 'errors' against the source image). I want to hurry up and finish this app, and start work on the tilemap app.
|
|
|
Post by elmer on Dec 4, 2019 7:23:52 GMT
Update: I converted the color matching algorithm to use CIE LAB. Excellent! I do hope that the whole process will be batchable so that it can be used for video without an artist having to clean up every single frame individually.
|
|
|
Post by turboxray on Dec 4, 2019 14:26:53 GMT
Update: I converted the color matching algorithm to use CIE LAB. Excellent! I do hope that the whole process will be batchable so that it can be used for video without an artist having to clean up every single frame individually. That would definitely require a little more work (not the batch part haha), but yeah since you brought up that huvideo clip.. it's been on my mind every day (lol been reading research papers on color space and color reduction on my free time at work). Originally, this app when it was just a converter, allowed for 8x4, 8x2, and 8x1 tiles! You know, the old old trick where you reposition the map on each scanline so get finer control over what rows have access to whatever subpalettes. Even toyed with the idea of doing 15 subpalettes and 1 dynamic one (if I did my math right, could be updated in about 4-5 scanlines). Of course, h-blur technique could work really well for video too (I had Gulliverboy huvideo routine hacked at one point with hblur). 60hz hblur (shift every other scanline buy one pixel) works with RGB, Comp, emulators, etc so it's a decent approach. A combination of tiles and sprites would work (5bit tiles separated into tile|sprite set) for the TeD if the cpu isn't hung up on polling like with the CD drive.
|
|