Search results

I guess that works in a pinch, but it's not the same thing. Having the actual NuBus bracket is nice as it helps secure the card in the slot.

Yeah. In the case of the Lapis PCS, the Chrontel CH9201 clock generator needs 12V for its analog supply.

Just wanted to say, interesting project! I like the idea. May be useful for "lonely" cards that lost their breakout box. Do you know sources for blank NuBus brackets? I have some ideas and that might come in handy.

Oh yeah, makes sense. I have a 12" CRT (640x480 monochrome LC monitor) and that one seemed to work with the Lapis PCS.

It's nice to hear from people on "the other side", if you will -- those who were making that hardware we're looking at today. I'd be curious as to why Lapis designed their FPGA gateware the way it is, and what kind of monitors they tested it with -- maybe the older monitors were more tolerant of...

Thanks! This fix was challenging, too, because I had to figure out a way to get it working with minimal editing. Basically, working with the available routing resources, making sure not to short any other nets, dealing with limitations like how switch matrices don't support all possible pin...

I have put up a first version of my Xilinx XC3-family bitstream viewer online. It is over here: XC3000 display The source code can be found on Github over here. What is this? It is the tool I have been developing in my other thread, the one about the Lapis ProColorServer. It is built from...

From what I read, there are key combinations that are alternatives to programmer switches -- handy for something like the IIsi, which lacks these switches. Command+Ctrl+Power to reset the Mac, that one works fine. Command+Power to send an interrupt, that one doesn't work. I'm not sure why...

Yup, works absolutely fine!

The final status update about this project! This is the part of the horizontal counter logic. The counter starts at EB. Logic blocks ED and EE check for the sync and blanking conditions, respectively. They both take 5 inputs: bit 0-1, 2, 3, and inputs from other logic blocks which check bits...

The voltages seem good: 5.02V on 5V, 12 and -12 are also good. However it seems that the +12V on the Lapis is 0... Edit- doh, stupid problem. The +12V pin in the NuBus adapter's PDS connector was bent. The Lapis PCS needs +12V to generate its pixel clock, but I guess the HRVC doesn't use it...

I'm running into a weird issue with my IIsi NuBus adapter. Basically, if I put a Lapis ProColorServer II in it, the Mac doesn't boot -- it gets stuck on the gray pattern screen, doesn't do anything else, doesn't display any cursor or boot icon, doesn't try to access SCSI. But, that's the thing...

I made a quick FPGA emulator thing, so I could confirm my observations before making any attempts. Good thing I did, I'd read some of the check values wrong, and in practice the check values for the horizontal counter are offset to account for propagation delays. The HBlank values are actually...

I was looking around and saw this, just wanted to say, super interesting!

I couldn't resist, looked at the equations for the various counter checks in the first Lapis PCS bitstream (which outputs 640x480 60Hz). The values I got out of it are as follows: VBlank start: 480 VSync start: 483 VSync end: 486 VBlank end: 524 Visible area: 480 / Front porch: 3 / Sync pulse...

Bit of a status update. Maybe at some point I should make a dedicated thread for this. Anyway, I'm mostly done with bitstream parsing and display. I'm working on tracing paths now. (btw, the code is over at https://github.com/Arisotura/xc3000/tree/main if it's of any interest) This is what we...

Lil' status update. I mostly finished making this view. It's largely algorithmic so it adapts to all the XC3000 family layouts. Only things is that the XC3020 has some subtle differences and I'll need to make sure these are supported correctly, and XC31xx family chips have a few extra...

Status update: I finally finished mapping out the XC3030 bitstream. The only thing missing is the misc configuration options like TTL/CMOS, pullup, ... Now I need to code the visualization tool. I have some ideas to make it adaptable to the entire XC3 family. I might backport it to the XC2018...

If you're tracing from an output pin, you'll want to find all the input pins that are connected to it, yeah. But if you're tracing from an input pin, I think you want to know which output pin connects to it, so ideally you'd want just that. Unless I'm mistaken. Also, your bitstream makes use of...

Oh yeah. The way I originally did the tracing was to start from an output and find all connected inputs. I could look into adding backtracing for inputs. The tricky part is that the tracing data I generate includes all connected inputs, so ideally I'd need to exclude those that aren't relevant...