Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/25/21 in all areas

  1. Hello Everyone! I received the parts for the third Prototype on Tuesday evening and spent a good chunk of that night and a bit of yesterday morning getting it worked out. I had to get my code moved over to the ATTiny861 before the board would even power on. This turned out to be pretty easy now that the I2C header will also work as an Atmel ISP programming header. Of course, I'm pretty much going to make a mistake somewhere on a board of this size, and this time is no exception! Fortunately, they were easy to spot and the actual logic is working as it should. Or at least as I designed it. Two of my mistakes are visible in the pic, see if you can find them. One is just cosmetic, and the other is a bodge job on a chip which I will admit, is next to impossible to see in this photo. The less easy to spot issue is that I used the stand-by power to power the microcontroller, but I put pull-up resistors on the I2C lines (and SPI programming lines) to the system voltage and not the VSB. I did this on purpose as I didn't want to pull these lines high while programming the microcontroller, but need to pull them high for I2C. The net result is that leakage was happening backwards through these resistors when the data/clock lines were high. Enough to power on the LED on the motherboard with no other ICs plugged in. Took me a minute to figure that one out, but I think I will just throw a few more diodes in to protect this from happening. I suspect issues like this are sometimes why you may see a lone crusty resistor on an old PCB after years of use. Easy fixes all around! One last issue is that the parts sourcing scourge which has been affecting the world is also affecting TexElec! Yes, we can't get parts in for some of our products, and as time goes on, it seems like it may get worse before it gets better. And now, it has hit the X16 project! I am unable to get the FPGA and the DAC for the new Version 4 VERA, so we're still running V3. The main difference has to do with hardware deadlocks on the SD card, so functionally, it's fine. However, the lead times are a bit concerning. I'm looking into some other suppliers now, and hoping for the best. For now, here's a pic of the new machine, with no wires all over it! Take care! -Kevin
    3 points
  2. But popping a 65816 into the CPU socket won't add the "one extra chip", because it has to be in the motherboard. Popping a 65816 into the CPU socket in effect gives you a 65802 with slight bus incompatibilities (SYNC is replaced by VDA/VPA and IIRC the clock outputs are DNC and a reset input). And a bus mastering 65816 card would be pretty much the same thing, though more room for circuitry to bridge the bus incompatibilities ... including masking out the bank address from the data lines. I would be entirely unsurprised if the problem in writing VERA is the bank on the data bus followed by the data confusing Vera in a way that is not an issue with the 65C02 write cycle. Nor would I be surprised if the bus cycles for some of the chips "work" with the 6502 but just make it, and small variations in actual read or write delays associated with the transition between bank mode and data mode make the timing too tight to work. But if you can get a bus mastering card to work, you get the pcode interpreter with the accumulator in 8bit mode and indexes in 16bit mode, with ops ending with JMP NEXTOP or an eight byte NEXTOP macro: NEXTOP: INY : LDA 0,Y : TAX : JMP (OP1,X) The thing is: since it can run 6502 assembly code, can run the same pcode as the 6502, except faster, and can host a compatible ROMBASIC interpreter, except faster, and since assembly code can test whether it is running on a 6502 or 65816, it might actually work as a 3rd party enhancement. Then it would only breaks running CX16 code if people use any of the four individual-bit-addressed operations in their assembled code, so it just needs "enough" of an install base so people shy away from doing that.
    2 points
  3. The 1541 disk drive had its own 6502 IIRC.
    1 point
  4. Both the SNES and Sega Genesis had sound coprocessors (the SPC700 and Z80, respectively). These were typically used to run music playback routines independently from the main processor. Additionally, several SNES games included the SA1, a secondary processor based on the 65C816.
    1 point
  5. My personal and theoretical ultimate 8 bit machine, would have at least a second 6502 as a coprocessor. This could serve many functions within the system, but the presence of the processor would make the development for the machine quite a bit more interesting. It would probably be far too complex, especially if it involved shared memory space, but it is fun to think about.
    1 point
  6. 1 point
  7. Bruce, it sounds like that card would be nice to have!
    1 point
  8. Russian speaking (though Ukrainian by origin) project "sinc LAIR" now in English and presents first translated video about Sinclair Pandora Project Z88: https://odysee.com/@Sinc_LAIR:3/The-Last-Sinclair's-Computer----Pandora--Project--Cambridge-Computer-Z88 Original YouTube channel: https://www.youtube.com/channel/UChC1Gcl-1bOkNPPzN_owcVg Patreon: https://www.patreon.com/sinc_LAIR
    1 point
  9. Music Player Library for BASIC Programs View File I wrote a library to enable BASIC programs play music in the background. It is compatible with Simplest Effects Sound library I released a while ago. To demo the library I included two BASIC programs: PLAY.BAS - Playing Twinkle Twinkle Little Star - it demonstrates the BASIC program doing other stuff including calling simple Effects HOUSE.BAS - Playing House of the Rising Sun - it demonstrates a bit more complex music Full Tutorial and source code is available from my blog: https://www.8bitcoding.com/p/music-player-library-for-basic-programs.html Submitter DusanStrakl Submitted 01/09/21 Category Audio Apps  
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use