Jump to content

bbuchholtz

New Members
  • Content Count

    26
  • Joined

  • Last visited

Community Reputation

10 Good

About bbuchholtz

  • Rank
    Space Invader
  1. Preordered mine. Thank you for all of your hard work and dedication to this project! -Brian
  2. If nothing else, it'd be great if the marquee file was a non-binary format, to allow for some degree of manual editing...
  3. 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
  4. Still for sale? How much were you wanting for it? -Brian
  5. Maybe this will come in time for Christmas -Brian
  6. This looks great! Can't tell you how excited I am about the progress you made -Brian
  7. 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
  8. Sorry if this was mentioned before... Is the Wifi module only used for ROM loading, or does it serve some multi-user function? -Brian
  9. 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
  10. 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
  11. 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
  12. 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
×
×
  • Create New...