bbuchholtz

Does anyone have a ROM dump of REBEL Star? -Brian

Preordered mine. Thank you for all of your hard work and dedication to this project! -Brian

Are these still for sale? -Brian

If nothing else, it'd be great if the marquee file was a non-binary format, to allow for some degree of manual editing...

Apologies; I misspoke.

Great work SainT! My preference would be to avoid the creation of a monolithic custom ROM file, containing box art and save states. I'd much rather use some sort of metadata file and discrete files for save states. Ideally, this would allow users the ability to mix and match save states. It would also help keep the ROM file unadulterated. -Brian

Ordered one! -Brian

Still for sale? How much were you wanting for it? -Brian

Maybe this will come in time for Christmas -Brian

This looks great! Can't tell you how excited I am about the progress you made -Brian

I'd personally much rather prefer having people ask me constantly on how to get onto a preorder list, than there not being any interest at all... It might be good to start finding out how many people want one, to start planning out quantities for production... especially if any of the parts are hard to source. Obsolete consoles often require obsolete components. It's sounding like the BoM is pretty well worked-out and most of the remaining effort is software and PCB revisions. -Brian

Sorry if this was mentioned before... Is the Wifi module only used for ROM loading, or does it serve some multi-user function? -Brian

Looks amazing, especially considering "it's just a prototype"! I'd offer to help solder (since it's tedious), but I'm across the pond Keep up the good work - I'm closely following this thread! -Brian

Hey Guys, I've started on my PIC programming. Full disclosure: I'm not a great programmer; I'm learning as I go. But, I'm feeling good about the progress I've made thus far It's turning out, the sync summing aspect of this project is the easy part. Microchip XC8 supports bitwise. So, I can XOR with one statement. Combining hsync and vsync is as simple as: CSYNC = HSYNC ^ VSYNC; The hsync delay is the more challenging part. But, I have an idea! Remember those old portable CD players? It used to be that if you bumped them, the laser would lose focus and the song would skip. Eventually, an "anti-skip" feature was introduced. Instead of directly outputting the audio, the bitstream would first be deferred to a buffer. Why not do the same thing with hsync? Obviously, we don't care about anti-skip. But, maybe we could use this as a method for creating a "delay". I already have a routine for reading pins and bit-shifting the values. This is what I plan to use for reading the jumper settings: unsigned int Read_Jumpers(void) { // Read jumper settings unsigned int Jumper_Settings = 0b00000000; // Initialize input buffer Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_0; // Store DEF_JUMPER_0 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_1; // Store DEF_JUMPER_1 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_2; // Store DEF_JUMPER_2 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_3; // Store DEF_JUMPER_3 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_4; // Store DEF_JUMPER_4 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_5; // Store DEF_JUMPER_5 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_6; // Store DEF_JUMPER_6 into Jumper_Settings Jumper_Settings = Jumper_Settings << 1; // Bit shift one LSB Jumper_Settings = Jumper_Settings ^ DEF_JUMPER_7; // Store DEF_JUMPER_7 into Jumper_Settings return(Jumper_Settings); } The above code as be used for reading and storing hsync states. Only difference would be reading from the same pin, multiple times. Much like sequentially storing eggs in an egg carton. Each "egg" would represent the hsync state, at that moment in time. However, my "egg carton" isn't big enough. As far as I can tell, I'm limited to 8 bits (states). I've been banging my head against the wall, trying to get around this limitation. Then it struck me... why not simply use multiple egg cartons? I can use the same methods for reading/writing a single byte, as I would for multiple linked bytes. Since I will be repeating this code, I plan to create a set of macros, for manipulating bits. Perhaps this will be a good excuse for me to learn structures and unions I'll keep you posted on my progress! -Brian

I apologize in advance, for my basic question. I'm trying to put csync into terms I can understand. Are the following true: If vsync is low, then csync equals hsync. If vsync is high, then csync is the inverse of hsync. -Brian

I've been poking around on Microchip's website. So far, the PIC16F1619 doesn't look bad: http://www.microchip.com/wwwproducts/en/PIC16F1619 Highlights: - 17 I/O + 1I (20-pin) - 125 ns minimum instruction cycle - Interrupt Capability - One 8-Bit Timer - Four 16-bit Timers - 10-Bit Analog-to-Digital Converter (12 channels) - 8-Bit Digital-to-Analog Converter - Fixed Voltage Reference (FVR): 1.024V, 2.048V and 4.096V output levels - Complementary Waveform Generator - Two Comparators - Zero-Cross Detect - Internal or External Oscillator I'm thinking I could use a crude jumper-based ( 8 ) binary selector ( 256 ) values. That number of steps should be plenty of granularity for hsync delay. We could probably get down to a resolution of 1 or even 0.5us. Does this seem to be headed in the right direction? -Brian

I don't see any reason why hsync delay couldn't be adjustable, using the PIC method. I could dedicate some of the I/O pins to a "user interface". It could be something like up/down push buttons, or set using jumpers. Although the jumper method would allow for fewer settings, it would persist after a power cycle. I'd rather not add the complexity of some sort of battery backup or an external NVRAM implementation. Unless there are PICs that now have some sort of NVRAM built-in. I'd have to check... I'm not a super expert at RGBHV. I may need a little help interpreting the signals... -Brian

Regarding sync combining and horizontal timing, what are your thoughts on using a PIC microcontroller? I have some experience in working with PICs. May offer a little more flexibility... -Brian

Thank you! This was very helpful -Brian

I have the Japanese FZ-1, with the VP536 encoder. So, I'm hoping that I can successfully build an adapter board for the BT9106 or BT9107. Are there any notable pinout differences between the BT9106 or BT9107? I know that you had some success with the BT9106... I know that you found an RGB selector on pin 13. Are you pulling pin 10 high or low? Also, did you end up pulling pin 14 low, or leave it floating? Also, are you pulling sync from pins 45/46 or 54/55? Or were you able to find a CSYNC from something like pin 8? Lastly, does pulling pins 58/59/60 low/high change video mode (i.e.: PAL/NTSC)? Sorry for all of my questions! -Brian

Hey Guys! I thought I'd join-in on your party I'm looking to try using the BT9107KPJ. Thank you Taijigamer for suggesting this idea! I've already ordered a couple of CD-i 210/40. They should be here any day... CD-i Fan was kind enough to provide me a service manual for the CD-i 210. This should help reverse engineer the video encoder. I plan to use the NCS2553 for RGB amplification. And probably some sort of circuit based around the 74HCT86 for sync combining. In order to make installation simple, I like something such as the W9327-ZC158. I have a good start on my PCB. Hoping it attached ok. Does anyone know if the BT9107KPJ has an internal VREF? Or do I have to supply an external VREF? I'm guessing this would be +2V. -Brian

I would also like to buy one. Looks like I'm on another waiting list I'm feeling frisky. Is color #9 (dandelion) still an option? -Brian

Yes, I realize - I was trying to help compile a list of questions -Brian

I'm surprised that my Sticky idea was met with so much resistance I thought this would have been a good starting point, for any new reader stumbling across this thread for the first time. This would also benefit those who have stepped away and wanted a quick update. Plus, this would help cutdown on posts asking the same question a dozen times (reduce noise). I was thinking something like a simple FAQ or feature/capability list would be highly beneficial: Platforms supported: Jaguar Cartridge, Jaguar CD? Old cartridge plastic case or injection mold? Supported media: SD, Micro SD? Maximum capacity? Supported filesystem? Support for folders? Game loading SRAM or Flash-based? Support for game saving? Support for saving game state? Game Genie support? How are firmware updates applied? USB port for debugging? Etc... I'm sure missed something else... I know the question of a waiting list has been asked many times. So, why not run a poll for those interested in buying this? I think if you knew if 5, 50, or 500 members were interested, this would help you make design decisions. -Brian

Can we maybe have a sticky that summarizes the project and current status? I agree, it's quite challenging digging through over 20 pages, trying to find that nugget... -Brian