Jump to content

JohnPCAE

Members
  • Posts

    829
  • Joined

  • Last visited

Everything posted by JohnPCAE

  1. I have a question regarding the KB bios at 7000. Can anyone point me to the code in the EXEC that kicks it off? I'm trying to run the KB bios after I have the ACC set up but it's not working. I'm wondering if there's something special that I need to do setup-wise before jumping to the KB ROM.
  2. After adding more instructions to the ACC, I think I've got the kernel fully ported. There are still a lot of unknowns, though, especially with respect to interfacing with the hardware. For example, when a key is pressed, how does that affect the keyboard registers (i.e. what does the code see)? 6502_ported.txt 6502 pseudocode.txt
  3. It's a tight fit, but I squeezed support for 64 new instructions into the ACC: P6INX, P6INY, P6DEX, P6DEY, P6TAX, P6TAY, P6TXA, P6TYA, P6LDAA, P6LDXA, P6LDYA, P6LDAAX, P6LDYAX, P6LDAAY, P6LDXAY, P6LDAI, P6LDXI, P6LDYI, P6LDANX, P6LDANY, P6STANX, P6STANY, P6STAAX, P6STAAY, P6INCA, P6DECA, P6ORI, P6ANDI, P6EORI, P6ORA, P6ANDA, P6EORA, P6ASLA, P6LSRA, P6ROLA, P6RORA, P6ASLAA, P6LSRAA, P6ROLAA, P6RORAA, P6CMPA, P6CMPI, P6CMPNX, P6CMPNY, P6CPXA, P6CPXI, P6CPYA, P6CPYI, P6BIT, P6ADCA, P6ADCI, P6ADCAX, P6ADCAY, P6SBCA, P6SBCI, P6SBCAX, P6SBCAY, P6PHA, P6PHP, P6PLA, P6PLP, P6RTS, P6JSR, P6JMPI Each of them emulates a 6502 instruction. While this isn't the entire opcode set the 6502 supports, it accounts for the vast majority of opcodes in the kernel. The result is code that's nearly one-for-one with the original. In fact, after I assemble it, the result is over 512 locations shorter since Intellivision code is more compact in some cases (mainly because it can store a 16-bit address in one location instead of two). One gotcha that I had to deal with has to do with how the stack operates. The CP-1600 uses an upward-moving stack while the 6502 uses a downward-moving one. So I had to stop using any CP-1600-based stack instructions and use only 6502 ones instead. 6502_ported.txt
  4. I figured out a bunch of stuff today such that it's worth a post: 6502_ported.txt 6502 pseudocode.txt
  5. Fixed a lot of relative addresses and also created some pseudocode. 6502_ported.txt 6502 pseudocode.txt
  6. No, it's nowhere near ready to run on the ACC. There are still way too many unknowns regarding some of the data structures inside it. I think I'm going to need help with those. This is a long-term project. I crawled through the code and fixed up how it sets flags. There was a lot of redundant code and a lot of errors. 6502_ported.txt
  7. Your post got me thinking, though: there are a lot of cases where I don't need to set the flags because a following instruction will overwrite them. I'm crawling through the code and optimizing the setting of flags. It turns out that I can remove a ton of unneeded code.
  8. Wouldn't that mess up the zero flag though? I'm porting it to ACC assembly, where every instruction takes only 1 cycle. Here's another version where I fix handling of ADC instructions. This one ensures that all flags (including carry) are set properly. 6502_ported.txt
  9. Remember that the 6502 is an 8-bit processor, and the sign bit needs to be set if bit 7 is set. The CP600 only sets it if bit 15 is set, which would never be the case here. Hence the SWAP instruction: it moves the contents of bit 7 to bit 15, setting the sign bit if it contains 1. I fixed how I handle the stack and how I handle certain jump instructions. 6502_ported.txt
  10. I decided to take a stab at porting the 6502 ROM from the Keyboard Component to ACC assembly. The idea is for the ACC to be able to emulate a Keyboard Component. I don't know if it will be possible, but I'm posting what I have in the hope that it will at least help with reverse engineering the Keyboard Component. I have nearly all instructions translated, but that definitely doesn't mean that it will work. There are a lot of questions about how the code deals with code vectors and data records, for example. At any rate, perhaps it will provide some insight into the KBC's 6502 kernel. 6502_ported.txt
  11. Updated the hardware BOM. The 08 (AND) and 04 (inverter) chips need to be of a specific type for clear video. Advanced Console Component 20240113.zip
  12. I hasten to point out that everything needed to build one of these is available (see the attached ZIP). I'm guessing they cost $100 to $150 to make. The hardest parts to acquire are the EDAC cartridge connector and the power supply: those can take weeks or even months to acquire if they aren't in stock. I've been getting the purple parallel port jacks by buying cheap PCI parallel port cards and desoldering the connector, but you can get new ones (in black) pretty easily. I've tried finding anyone selling purple connectors to no avail. Another word of caution relates to the 7202 FIFO chip. 25ns or less will do, but some sites like Mouser demand a huge minimum order. I've had better luck at Digi-Key for getting those. Advanced Console Component 20221217.zip
  13. They provide several main features: - Overlay video (extra sprites, 40x24 and 80x24 text, bitmap graphics modes) - 64k-words of bankswitched RAM that's shared between video and the coprocessor - Emulated coprocessor with a much-extended CP-1600 instruction set - 8-bit parallel port I chose a parallel port because it's easy to implement and easy to program. You presumably could use it to interface to lots of things with the right software.
  14. I have 5 more ACC boards, and I've started building the first of them (that's the one on the top). I don't have all of the chips I need to complete it yet, but over time I plan to have a total of 9 units (one is for me). I don't know how long it will take, we'll see. When they're completed, maybe I'll build another 5 (boards come in batches of 5). Who knows? It's only a shame that we don't have something like PhillyClassic anymore where I could drive up and show one off (and maybe hand some out!)
  15. Tiny speed optimization to the colored-squares code (remember to use the side buttons to switch modes). Added a lot of comments to the colored-squares code. raycast_20231227.zip
  16. No, my point is that it's not an Inty game, since AFAIK no one has any ACC units (even though I have 2 complete units ready to ship to interested devs).
  17. You need an ACC unit (see the Bird's Nest forum thread) for hi-res graphics on the Inty.
  18. It looks fantastic, but I think it needs something. Maybe the background changes as you progress, or is more varied? Powerups would make things interesting, too. Keep up the good work!
  19. You know, there is also the ACC that I developed. I'm not interested in manufacturing them, but the design is both frozen and open for anyone else to. And it's documented and even comes with a sample program. It's not an Intellivision III but it does give the Inty many of the Inty III's graphics capabilities. And it comes with a coprocessor that's emulated in software. The only caveat is that if you use an Inty I with it, you need to implement the System Changer mod to really take advantage of it (it will work without the mod but the overlaid graphics will be rather dim because of the heavy resistor the Inty I puts inline with overlay video).
  20. I've built and tested the last board that I have, which gives me three spares. Since I have surplus parts, I've ordered another set of 5 boards. I have no idea how many of these I plan to build, but it gives me something to do. I don't plan to send all of them out for free as there is a cost to making these, but the offer to send free ones to interested developers is still out there.
  21. A few updates: 1. Corrected a handful of characters in the built-in fonts. They had been incorrectly shifted left by a pixel. 2. Updated the silkscreen and Gerber files for the mainboard to reflect the correct chip types (e.g. 74HCT). 3. Added Appendix C to the documentation that shows all built-in font characters. 4. Added Appendix D to the documentation that explains how to load new firmware to the Raspberry Pi Pico. Advanced Console Component 20221217.zip
  22. We can do you one better. Here's the Intellivoice service manual, which includes a complete schematic: The Intellivoice connector would be a great solution for FujiNet, but it can also be problematic. Data pins D0-D7 are open-collector, but not all Intellivoice units have the required pull-up resistors R28-R35. So anything you plug into it should provide its own pull-ups. A simple SIP resistor pack can do the trick. Also, many Intellivoice units don't have the IDC connector at all. Those would have to be retrofitted. In my Intellivoice II project, I provide the expansion connector but not the pull-up resistors. Intellivoice_Service_Manual.pdf
  23. It does, but right now the ACC is the only thing that provides any sort of external device connectivity to the Inty. As to why I chose a parallel port, it provides a ton of capability while also being an industry standard. You can connect any old printer from the 80's or 90's and it will work as long as you have the software to drive it. Or you could rig a DIN connector to its pins and bit-bang the Commodore 64 IEC protocol if you wanted to. Or you could connect a resistor ladder to the data pins and get crude analog sound. Or anything else you could do with a PC's parallel port.
  24. The decoding is done in the Raspberry Pi Pico. It does all of the heavy lifting. It's a dual-core microcontroller. One core talks to the Intellivision bus and emulates a coprocessor and the other core handles video output.
  25. All ACC registers are at $007E and $007F. You select the register by writing to $007E and you set (or read) the register's value at $007F. If you've ever done CGA, EGA, or VGA programming, it will look very familiar. I do something similar with my USB card by putting its registers at $007C and $007D (so please don't use those).
×
×
  • Create New...