Jump to content

Spaced Cowboy

+AtariAge Subscriber
  • Content Count

    257
  • Joined

  • Last visited

Community Reputation

397 Excellent

About Spaced Cowboy

  • Rank
    Moonsweeper
  • Birthday 05/17/1969

Profile Information

  • Gender
    Male
  • Location
    San Jose, CA
  • Interests
    Electronics, CNC machines, Saltwater fish, general creative stuff

Recent Profile Visitors

3,770 profile views
  1. Aaaand edit: I'm an idiot. The address-bus values *between* those above were constant at $E001, so I was assuming that was the CPU (being halted every other clock) constantly accessing the same location. That's not the case Looking at the traces after Antic has stopped /HALTing the 6502, ... it's clear to see that the CPU is what is accessing $F306,7,8,9,A,... Not Antic. Which means Antic is accessing the $E001 address a lot. On the XE, $E000 is the standard domestic character-set offset, and I'm assuming the XEL is booting into basic (because I didn't have a keyboard or screen attached) and getting the character-based screen data. Looking at other access patterns, it seems this is Antic reading a byte representing a row in a character (in this case the next-to-top-row of a space character which data is stored at $E000 through $E007). There are other sequences where Antic holds /HALT low for 80 clocks at a time, interleaving 40 read-character-at-screen-position with 40 bytes describing this scan-line's representation of that character. It's all becoming a bit clearer now This is all going to feed into a script I'm writing which will take these bus-traces as input and attempt to parse out the screen display from them based on triggering callbacks from events it discovers in the trace sequences (clk going high, /halt going low etc.). Doing it in software is a lot easier than doing it in hardware, and I can then just port the algorithm to the hardware world once I know it works in software
  2. So, it seems my 130XE is indeed expletive (ahem) ... not fully functional, at least with respect to its external address bus. Here's the screenshot of an 1088XEL trace: ... where I happened to catch Antic doing a refresh of the 256'th column, so the address bus is all-on. This image also shows Antic doing memory-fetches for the graphics data, immediately after the DRAM refreshes. I am a little confused over the accesses at the moment though, it looks as though Antic's memory access are to: $F30F - unknown $02FC - Internal hardware value for last key pressed ? $F310 .. $F311 .. $F312 .. $F313 .. $F314 .. all unknown $F3FD - unknown $F2FD .. $F2FE .. $F2FF .. $F300 .. $F301 .. all unknown All of these seem to be inside the OS ROM (and not where the charset is at $E000 .. $E3FF) unless my edition of "Mapping The Atari" is out of date, or unless the XEL replaces the ROM somehow ? And yes, I checked that the low bit of the high nibble of the address wasn't always being set - once bitten, twice shy Still, the reality is that the traces are what they are - so I guess I just have to figure out what they mean now
  3. So I didn't intend to have another post this quickly, but this is kind of interesting Since I have the bus traces from an actual 130XE, I'm writing a bus-decoder in Objective-C on the Mac before I try to do it in verilog, it's far faster to debug it in software when I can run tests as part of the build process Once I know I have a working algorithm, I can then translate that to verilog for the CPLD. Annnnyhoo - I noticed something odd... Under no circumstance was bit 4 of the address vector ever being set. I thought that was a bit weird, so this morning I went and wired everything up again (40 flying leads!) in case I'd missed one somehow in the previous run. Nope. I still didn't get anything on A4 (bit 1 of the second nibble). So I wondered whether the analyser interface wire was broken, and changed out the flying lead to a different port (this thing can sample 256 lines in parallel at 2ns resolution!) - still nothing on A4. So I un-wired everything, took the interface board ... back to my desk and used a continuity tester to make sure that A4 (3rd pin along on the top row) was connected to the pin correctly, and there hadn't been a fabrication error. Yep, that beeped. So then I double-checked that it *was* in fact the third pin along on the top row that I ought to be sampling for A4, which seems to be the case. Which leads me to believe that my 130XE is buggered, or at least it's A4 line to the outside world is - unless there is some unbeknownst-to-me reason why A4 should never be high ? As an aside, this version of the breakout board has /REF and /HALT brought out onto it, and also vends a cartridge port interface, so I can plug in a cartridge and look at how /MPD and /EXTSEL work when something is actually plugged in. Here's ANTIC doing the RAM refresh... ... It looks as though /HALT is asserted one clock before /REF is, and the bus refresh address changes when /REF is active. This is how I found the problem, actually - I was looking at Antic counting up the columns, and it does 9 (weirdly, not 8..) accesses within about every 64 uS with a heavy front-load within those 64uS, meaning it cycles through refreshing every row roughly every 18ms. Looking at the address though, it went $FFCC $FFCD $FFCE $FFCF $FFE0 $FFE1 (so the $xxCx ought to have been $xxDx) and looking around, I saw it was a pattern. A previous sequence was $FFAE $FFAF $FFC0, ... where the $xxAx really ought to have been $xxBx. So, I think I have a broken external port. I've got my 1088XEL and I'll bring that in and see if I see the same thing (which would be *very* weird) and go from there...
  4. All of those things. If you read back in the thread, some of the things I think you can do: "Memory Apertures" allow arbitrary remapping of the 32MB of SDRAM on-board into the 6502's memory map We have access to the /HALT line on the bus. We also know the video requirements for the current ANTIC scanline so we can predict when ANTIC will want access. The rest of the time, we can /HALT the CPU and read/write from/to memory ourselves. The STM is the ultimate co-processor ANTIC uses the bus to fetch the display list and display data - so we can reconstitute the video display just from the bus accesses, which are conveniently signaled by ANTIC using the /HALT line (and not the /REF line, which we also have access to). This is the basis for the video-out-to-HDMI plan I think it might be feasible to write software-only peripherals on the R-Pi. It ought to be possible, I think, to have a program running on the R-Pi which has access (via an API) over the USB-bus to the STM32 in some standardized way, and the STM would then vend that software "Device" to the XL/XE as a peripheral sinking/sourcing data The CPLD has an embarrassment of riches with regard to i/o pins, so I put 4 PMOD interfaces in there. All they need is a cable to be brought out to the outside world. There's also an internal expansion bus (to both CPLD and CPU) to link in anything else in the future that need more oomph than the stock slots provide for. Speaking of the CPLD, I have a 6502 design that runs at ~50MHz on that CPLD, and there's sufficient SRAM hanging off the CPLD to make it a full-blown co-processor... Networking is actually pretty trivial - you need a daemon on the linux box, and an API in cc65 (or Action! or whatever) that the N: driver can implement. Anything over open, close,read,write can be done with XIO, or you could go native and just memory-map things - so you set up a memory page, 128 bytes is buffer, 128 bytes for control structures, and the driver just reads/writes to those memory locations which cause transactions to happen to the Pi. Hard disks (USB-attached) are equally simple - just a buffer for data and transactional API for the transport - it's actually pretty much the same as the network model. The Pi has 2x USB-2 and 2x USB-3 ports exposed... I've plumbed the audio lines through, so if you can get line audio into the cabling on the Atari side (trivial with a 1088XEL, the pins are right there, a bit more difficult with the stock hardware) you can have audio sent over the HDMI link, in stereo even. Using something like a raspberry pi to reconstitute the display leads to some interesting possibilities - for example when the XL is putting out one of the APAC modes, we could recognize and render it correctly (ie: no black lines on alternate rows).. Things like that. To be honest, just having the gargantuan 32 Mbytes of RAM from the STM32 at hand could lead to some pretty freaking cool things I think the Pi is too good a deal to miss out on, so I expect most people to go for it, but you don't *have* to have it - the STM is perfectly capable of running the slots without the Pi being present. If you *do* go for the Pi, though, the goal is to have the best damn developer machine for the Atari that you could reasonably get in real hardware - deploying the binary can be done over the parallel bus, there are 2 HDMI ports (one for the XL display, the other a high-res linux interface for text-editing/compiling) and a relatively fast CPU to work with. I've been playing with the Pi-4 for a few days, and it really is remarkably zippy, considering its cost and form-factor.
  5. One thing I forgot to add in to the above price is the cost of the XL/XE interface board. This is pretty minimal, just a pass-through from one port-type (Atari cartridge) to another (mini-SAS), but it has some high-ish cost items on it (the mini-SAS connector is $7 and the Atari cartridge port is $4.50 from DigiKey, though given that that is through-hole, it might be a lot cheaper to source from Ebay). So figure adding another $18-ish for the board and cable.
  6. So, just to poke my head up over the trenches for a brief moment, the project isn't abandoned... I just got the impression that it was going to turn out to be too expensive for any significant take-up. To that end, I've been (off and on, it's been a busy year) rejigging it with cost in mind from the get-go, as opposed to thinking about that at the end It's now a 4-layer (not a 6 or 8-layer) board, and the parts are significantly cheaper. There are of course different trade-offs that have had to be made, so read on I've just run the latest incarnation through the cost estimator at PCBway (preferred over Seeed for cost), and got per-board prices of $99 (quantity:5), $65 (quantity:50) and $55 (quantity:100). This is for all the SMT work assembled, and includes the cost of the SMT parts. There's a fair few optional through-hole parts on the board (figure another $10 or so per board), and to keep the costs down I've been assuming that kits with the SMD done, but the thru-hole parts being left for the buyer to do would be acceptable. If you're not into soldering at all, I'm sure enterprising individuals would be willing to step into the gap Closer to the time, I'll get costs for a full assembly, and we can take a view then. For now the P.o.R is to only do SMT assembly (anything with red pads on the diagram below). There's a lot of green-holed through-hole parts, but they're not all necessary - most people will only want the slots, the power-in, and maybe the 3 R-Pi connectors.One benefit is that if you just want the slots and memory capabilities, you're pretty much done once you've added the slots and (probably) a case. The board currently looks like the below, and the basic design is to have a cable (I'm using a mini-SAS cable) from the back of the XL/XE to this motherboard. We can put the cartridge connector into that back-of-the-computer module, so there's no need to duplicate it on the motherboard. There's a CPLD to manage the fast turnaround times for the /MPD and /EXTSEL signals, and an STM32 handles the slots. Each slot has a dedicated UART with which it can talk to the STM32 whenever it wants, and the STM32 will schedule all the traffic into an ordered sequence of instructions to the host Atari. It seems to me that using a UART (which can be set to run at 115,200 or 1 Mbaud or 4 Mbaud by pulling pins low on the slot connector) is pretty much foolproof - every MCU under the sun has a UART facility There are a few mentions of the R-Pi4 on the annotated image below, that's because there's an optional R-Pi holder on the underneath of the board on the left-hand side. You can see the extent of the Pi where the dashed/dotted line is. The Pi is connected to the STM32 via the built-in 480 Mbit/sec USB link, which the STM will use to send the video signal (that the CPLD decoded from the Atari's bus activity) down. The R-Pi4 has enough grunt (I think ) to take the video data coming in over USB and zoom it up using the GPU/OpenGL to give a full-screen HDMI interface to the XL. Oh, and you get all the facilities that Linux offers too... The drawback is that a Raspberry Pi takes longer to boot (about 8 seconds on my Pi) than the XL/XE do, so you'll have to switch on the expansion board before you switch on the computer. To be honest, I seem to remember having to do that with anything I plugged into my old ST back in the day... I think this is a reasonable trade-off for more than halving the price of the expansion kit. You pays your money, and ... To set expectations, I'm hoping that the all-in price (including a 1GB R-Pi4, the cables to connect it in, and SMT assembly) will come to ~$130 assuming there's sufficient interest for the quantity-50 price. I'm also hoping to get myself a rather nice 3D printer this month (it's bonus week, so the yearly toy gets bought...) and I'm definitely keeping an eye on being able to print the case - this printer can do 27x15cm prints... Anyway, that's the update. Updates are not going to be anywhere near as frequent as at the start of this thread, but the project has certainly not been forgotten
  7. Yep. I ran the numbers on using an Arm microprocessor when doing my Parallel port expansion project as well, and given the interrupt latencies, the bus requirement to respond with /MPD and/or /EXTSEL within 48 nanoseconds of getting a valid address is a pretty hard requirement. 50ns is a 20MHz clock, it's all ok to do it via hardware in the old days because you didn't need the flexibility of programmable memory apertures or what have you. It's a bit different trying to do that in a software world... In the end I went with an FPGA. That way I could get very fast responses, and also have direct access to memory, giving me interesting opportunities for memory management I'm still (slowly) working on it, even though the project thread went radio-silent. I think the cost was a problem (and I think I've found a way around that, roughly halving the cost at Q50) and I've got a board out with Seeed now to test out some of the connectors. Anyway, just poking my head in - and letting people know I'm still playing/thinking about the PBXL, even though it might not seem that way
  8. Me too - I have a gigabit fiber connection, and a 64TB server with plenty of space on it yet Happy to trickle it in, if that helps your bandwidth, and happy to set it up as {ftp,http}.us.pigwa.net if you want ? [edit] Ok, mirroring has begun, and it's slowly trickling in (bandwidth-limited on the fetching side, and with delays between fetches as well). I don't want to put any strain on the source As things come in, this'll get more useful, but the site is now up at http://atari-archive.net/
  9. Just a ping to say I'm still alive, I haven't given up, and it's 6:30 am and I'm posting from work, which is why there's not been much any progress on the board this last month. I have a deadline to meet in a few weeks, and hopefully after that I'll find the time to carry on working on it - but between my work schedule, school activities, and planning the kids birthday next month, there's just been no time.
  10. Further updates: The SD card interface isn't playing ball. I think there's something wrong with the middleware I was planning on using, which means I'll either be trying to debug the SD card library I have, or writing one from scratch, which is a bit disappointing. The card responds to several calls, happily tells us its configuration, type and required settings, but then a call to get the card status always returns an error. The code is a bit opaque, so I don't think it'll be too easy to fix. We'll see. The other side of the board, of course, is the FPGA. There's a fair amount of prep-work involved in bringing up the FPGA - specifying all the i/o pins as being linked to a given named port in the top-level module via constraints, and specifying all the voltage specifications etc. On top of that, there's the actual module code to be written. In my (admittedly, limited) experience creating verilog for FPGAs, it's a good idea to have an overall diagram specifying how all these things are going to interact, so the first draft of that looks like: There are going to be a few clock-domains implemented using the DCM tiles in the FPGA, so that I only need a single clock input (which runs at 50MHz). The figures are only estimates of what I think I'll be able to get the code to do, so they may well change... I know I want SPI5 (input SPI from the ARM chip) to be as fast as possible so I can do oversampling and recover the clock relatively accurately. I know the host bus interface (purple) will only need relatively slow access, since that's a <2 MHz clock on the atari. I also know I can synthesize a 6502 core at ~100 MHz, so that'll set the green clock speed. The ARM can recieve SPI at up to 100MHz, so SPI6 can piggy-back on that. I want the decode and Antic code to be "as fast as possible", but that'll be limited by the ANTIC part I suspect. We'll see. Encouragingly, it's not an overly-complicated design. There's really only 4 paths through the design for data to flow, which means I can separate things nicely. I'll use wide-bit FIFOs, so I can encode data+context into a single word, and this is made easier by the FPGA allowing the use of Block-RAMs as FIFOs with widths up to 72-bits, 512 words deep... plenty for combined data+what-to-do-with-the-data information. With that out of the way, I have an input/output constraints file to write...
  11. Quick update on the board-bringup So the first thing to do, once the ubiquitous LED has lit, is get serial i/o working on the debug port. I duly connected it all up, told the app to io_writechar(huart2, 'X'), hit run, and .... nothing happened. no X for me. It took a bit of head-scratching to figure out the problem - I'm using the same connector as I use at work (a 10-pin JTAG pinout) because then I have access to all the cool hardware set up for board bringup. To get that to work with the open-source tools though, I'm going through a 20->10-way JTAG adapter, and that board doesn't propagate the serial line signals to the correct pins. No real problem, I soldered a couple of wires to the back of the board and connected it to a different serial->usb converter, so I still have serial output. Next up was the second serial port. This was a screw-up on my part. The circuit is fine, up until the DB-9 port, where I routed TX to the RX pin and vice versa. I must have looked at that circuit 1000 times, and I still didn't catch it. For this revision, it's not too important, I'll just run one of these between the board and the cable, and swap the lines over. Now that writing bare bytes to the serial port was up and running, I wanted printf() output (formatted text out). This is really useful in debugging to log something, so its always one of the first things I bring up. A simple call to printf() produced nothing, which is odd because printf calls into _write() which in turn you have to make output characters to the correct serial port using the __io_putchar() call. I'd done that, but I could see that the code wasn't being called (I put a breakpoint in it) by printf(). More head-scratching... There is the concept of a 'weakly linked stub' in programming, where a default (usually empty) chunk of code will be linked in, if the user-supplied code of the same name isn't supplied. I thought that somehow my own code wasn't being called, and the weakly-linked code (which does nothing in this instance) was getting the call instead. I spent quite some time figuring out that this wasn't in fact the case. Eventually, I was poring over the assembly output and I realized the code for _write() wasn't being compiled into the binary, even though I could see it ... *right there* in the IDE. If you've figured it out, you're ahead of me... The IDE generated this code (syscalls.c) for you, puts it into the source tree, but doesn't actually compile it until you move it to a directory named 'Src'. Wonderful. So, moving the file over, recompiling, and flashing it down to the board, and we have a working printf. "Hello World" rules again. So, serial out of the way, next to verify the clock speed was actually what I thought it was. There's a function library that comes with STM chips called the HAL (Hardware Abstraction Layer). One of the HAL_RCC_xxx calls will return the frequency in Hz, so it was just a matter of formatting the output using printf() into MHz for ease of reading... Finally (for this post), I wanted to check out the SDRAM. Using the data sheet, I calculated the parameters for this SDRAM, running it at 100 MHz (which is the max speed for the STM32H7). Enabled byte-lanes, burst-mode, set CAS and RAS timings, and various other things. Tried to access the RAM, and ... nothing. The CPU hit a bus exception and jumped to its exception handler. So, a bit more reading up on SDRAM - I generally use an SRAM on microcontrollers if I need more memory (I generally don't need anywhere near the memory available on this board), so I'd overlooked that you have to initialise an SDRAM with a particular sequence of commands. Laying down those commands in the correct order with the correct delays, and configuring the SDRAM MODE register to match what the STM32H7 would be sending, I could read and write to locations in the SDRAM memory space. The boot sequence is currently pretty short, but it looks like: SoS Booting. SoS Compile date: Dec 18 2018 @ 15:08:54 SoS Booting at 400.00 MHz SoS SDRAM Memory ok at both BASE and LAST All of which is duly printed out on boot The remaining peripherals are: ​USB (which I'm going to leave for now, getting the HID service up and running is not a trivial task) The SD card The video output The SPI interfaces to the FPGA The SPI interface to the slots The i/o expander But so far, so good. Nothing has gone wrong that isn't recoverable Simon.
  12. I'm not sure if this is worth a post from the not-me perspective, but it's a big deal for *me*, so I got SW4STM32 up and running, with openocd debugging configured, so I can code in Eclipse (which isn't my favourite IDE, but it's tolerable). What it does get me is a graphical interface to gdb, letting me interactively single-step through code running on the STM32H7 on my board. As an embedded developer by trade, this is one of those "thank ${deity} it works!" moments Sure, you *can* use gdb/lldb from the commandline, but it's much nicer to have all the information presented in the UI... I was a bit concerned because I usually use a work-provided debugger which properly handles the NRST signal, but the standard ST-Link hardware doesn't do that. Fortunately there's an option in SW4STM32 to do a software-reset rather than rely on hardware, and this worked on my STM32H7 chip. You need the reset to do the flash programming, so it's kinda important. This way, once you have a board, and have git-cloned the repository, anyone can update the firmware and flash it down to the board using free-to-use open source tools, and the cheap ST-Link2 programmer with a 20-10 way adapter.
  13. They gave me a complete refund the first time around. I haven't got in touch with them yet, but I will do this weekend. It's pretty fortunate that (a) the voltage regulator didn't blow up, and (b) that the major chips (the FPGA and the ARM chip) didn't let the magic smoke out. The "absolute maximum" ratings for both chips are less than 4 volts... Seeed did too - see post #133 above, but they didn't highlight the voltage regulator as a problem, and their photo was a bit fuzzy. Having said that, it is possible to see the pin-1 dot in the lower-left corner when it ought to be upper-right. I did check the SDRAM, ARM, FPGA etc. But I missed the 3.3v regulator.
  14. So the board came back from Seeed last night, looking a bit like: I say "a bit like" because the above is the fixed board. They did it again! They managed to get one of the chips the wrong way around... [backstory] I plugged in the 5v supply, and the three LEDs lit up to show that 1.0v, 1.8v and 3.3v were all being supplied. All well and good, I thought, but I got the multimeter out and checked... 1.0v ... good, measuring 1.003v 1.8v ... good, measuring 1.801v 3.3v ... wtf, measuring 4.3v SWITCH IT OFF. NOW! (ahem) so I was curious what I'd done wrong with the PSU circuit for 3.3v, I went back and checked it against the webench design from TI, and it all seemed to check out. I'd used replacement parts for some components due to availability, but it still seemed like it ought to work. I decided to wait until today when I could chat with the EE's at work. So today rolls around, and we link the board up to a nice variable bench supply, the 3.3v line is acting like a diode... No matter what voltage you feed in, you get input-voltage minus 0.7v out the other end. This is to say the least, confusing. It's supposed to cope with an input of 3.4v to 5.9v and still produce 3.3v. out comes the magnifying glass, and I bring up the board-layout. Yup, the chip is rotated by 180 degrees, it's amazing it didn't just blow. Anyway, I got the very nice lab manager (Janet) to de/resolder the chip for me, and we're in business. [/backstory] So, now I have 3.3v coming out the regulator, well okay 3.295v I was worried that some of the main chips may have died - so plugging in the debugger to the ARM core, I could connect via the SWD interface and read/write to the SRAM on the chip. That's a good sign... I also did a quick check on the JTAG connectivity to the FPGA, and that seemed to pass as well. My version of Vivado is too early to know about this particular chip, but it successfully probed the chip, got the chip-id, and said it had found an unknown device on the JTAG chain. I'm downloading the latest version of Vivado as I type, and once that's installed, I'll check it identifies the chip correctly, but it looks good right now... [update] I've installed Vivado 2018.3 now, and it recognizes the chip via JTAG [/update] I'll get Janet to re-orient the 3.3v regulators on the rest of the boards before I power them up, just in case, but so far, so good
  15. Yup, it's been a long haul, I'm really looking forward to getting them in my hands.. I think they're supposed to be shipped on Dec 7th. I have Simplify-3D for my original 3D printer, but it's not going to support the colour 3D-printer just yet - maybe the next version I've asked the site-admin at forum.xyzprinting.com to get me access to the "invite only" Da Vinci Color forums, we'll see. I knew their parts/consumables were expensive, but the filament is easy to hack (*cough* Hackaday *cough*), though unfortunately that wouldn't really help in this case because I don't know anyone else who sells the colour-absorbing PLA, or the inkjet refills. If I go this route, I have to accept that I'll be paying through the nose for consumables. I actually already have a Magic Box, and it does work on PLA, but to a lesser extent. You don't get the glossy look that you get from ABS, but it does smooth out some of the surface detail on the end-product.
×
×
  • Create New...