[Andlabs]

So over the past few days I've been playing around with visual6502 and perfect6502, building this, which I intend to use to hook up several netlisted things together. I have two questions:

1) This first question involves understanding how visual6502/perfect6502 works. In perfect6502, there are three Boolean properties that a node can have: value (called state in visual6502), pullup, and pulldown. While the value/state holds whether or not the node is actually transmitting a high current, the function to set a node sets the pullup and pulldown properties to the requested state and its inverse, respectively, which are later used to set the value/state for the group of nodes controlled by the node we just set. The segdefs blob used to define nodes specifies the initial pullup property only (that is, pulldown is not set during initialization), and the initial value/state I set to zero. What I didn't understand was what pullup/pulldown represented. According to this, "a '+' [segdefs indicates set pullup on initialization to true] indicates a resistor is connected to the positive supply and will turn on attached gates if not shorted out." So given how setting a node works, should I assume that all node have a pullup resistor that is used to control the value? What about pulldown resistors; would those go on the negative edge? And what is the significance of having both pullup and pulldown set to false on initialization, since setNodes will always ensure pullup == !pulldown?

2) The second question involves what I am doing with visual6502/perfect6502: right now, data accesses are high-level and done whenever the high-level MMU, called monitor (and stored in runtime_init.go; the file should really be renamed monitor.go and the runtime.go to hlekernal.go) asks for a pin value. Of course this is in violation of 6502 timing diagrams. Furthermore, the monitor is using its own clone of the CPU clock, instead of being driven by the 6502's two-phase clock output. What I want to do is have the CPU, MMU, and other stuff run as separate coroutines. In Go, coroutines communicate with channels, which are mechanisms which send at most one value from a sender to a receiver. Channels block: if there is no sender, a receiver waits for one; if there is no receiver, a sender waits for one. I tried several different approaches that directly hook output/bidirectional pins to channels on node set value in an attempt to improve timing accuracy, but this just caused everything to deadlock. I determined there are several spurious reads and writes on pin nodes, so the question here is: is there a reliable way to determine which pin read/write is one that gets read by an external device? Or do I need to manually reconstruct the timing diagrams? Or am I doing it completely wrong and will need to find a different way to represent pins than channels? Or is timing accuracy not even possible on visual6502/perfect6502 because of how it sets groups of nodes/transistors at once?

Please let me know if any of this is unclear and I can try to clear it up. Thanks!

This post has been edited by Andlabs: 17 May 2013 - 08:57 AM

[Andlabs]

Amending question 2; I might have a different possibility.

Here are the timing diagram from the May 1976 6500 series CPU datasheet:


Here's my monitor pseudocode:

Quote

Wait for clk2 to go low (REF "A")
Read the address bus, RW, and SYNC
If SYNC is high and the requested address is in the KERNAL
    Flag that we should call the fake KERNAL functions once clk2 goes high (which should also happen when the input clock goes high)
If RW is high (reading)
    Pull RDY high
Wait for clk2 to go high (REF "B")
If we should call the fake KERNAL functions
    Call them
If RW is high (reading)
    Write the byte at the requested memory address to the data bus
Else
    Read the data bus
    Save the contents of the data bus in memory

This code is run repeatedly until the emulator is closed.

Am I reading the timing diagram wrong? Thanks.

This post has been edited by Andlabs: 18 May 2013 - 08:15 PM

[Chilly Willy]

Um... it's hard to tell how much digital logic you know from the posts. If you haven't taken a class (or the online eqv), you really need one. Do you understand boolean logic? Synchronous and asynchronous state machines? How to make a minimal state machine verses a glitch free state machine? If not, you need to learn those first before you can work on CPUs at the hardware level. You should also be familiar with RTL, DTL, and TTL circuitry. Note - there's probably enough info on all this on wikipedia as long as you're good at learning from distributed sources of info without a teacher.

[Chilly Willy]

More on the second post...

Notice that the SYNC, R/W signal, and address bus are not stable until a certain period AFTER REF "A" (TSYNC, TRWS, and TADS). They are stable by REF "B", so you'd want to wait for CLK 2 high, not low. Waiting on CLK 1 low would probably also work since it's REF "B" - TD.

Notice that the data written by the CPU is not stable until TMDS after REF "B". Data read from memory must be stable no later than TACC from the other signals becoming stable.

[Andlabs]

Sorry for the delay in replying.

I know Boolean logic but not so much the other things; I assumed when my Google searches failed that what I was looking for was nontrivial. I do have my eye on one VLSI book to teach myself more of this, but I Imagine that won't be enough...?

Thanks with the second reply; that part about waiting for clk2 high was what I was thinking at first, but with the note on the other time durations, it looks like I'll have to do extra work to simulate the proper timings beyond what the existing simulators already can do, maybe... Thanks anyway.

This post has been edited by Andlabs: 22 May 2013 - 04:47 PM

[TmEE]

Those transition points you see on the graph vary wildly (but within the limits given). You will not gain anything by trying to simulate those effects unless the device you simulate is largely based on asynchronous logic. Most stuff is synchronous which means half a clock cycle is the lowest unit of time you will have to worry about. Rising and falling edges are the key elements in majority of designs.

[Chilly Willy]

It doesn't take a lot of knowledge for simple circuits - some boolean math, the workings of simple gates like in the TTL and CMOS chips (7400 series for example), and up to how an ALU works, or simple state machines. If we were talking college classes, one or two semesters worth of work. Unless you have trouble with math, it shouldn't be too hard.

Modern tools for things like CPLDs and FPGAs mean you can get by with doing the hardware rather like software. VHDL or Verilog permits making hardware using languages along the lines of Java/C++/C# in terms of complexity. Knowing how to use boolean math and how the gates work is still handy, but not nearly as critical.

[Andlabs]

Again, sorry for being late to this.

TmEE, on 22 May 2013 - 09:27 PM, said:

Those transition points you see on the graph vary wildly (but within the limits given). You will not gain anything by trying to simulate those effects unless the device you simulate is largely based on asynchronous logic. Most stuff is synchronous which means half a clock cycle is the lowest unit of time you will have to worry about. Rising and falling edges are the key elements in majority of designs.

So I should just have the cores give signals whenever they are asked for (which is what I have now) and receive signals whenever they are made available? That's what I have now before trying to make the adjustments I tried making in the original post, so I guess I was right the first time. Thanks.

Chilly Willy, on 23 May 2013 - 12:24 AM, said:

It doesn't take a lot of knowledge for simple circuits - some boolean math, the workings of simple gates like in the TTL and CMOS chips (7400 series for example), and up to how an ALU works, or simple state machines. If we were talking college classes, one or two semesters worth of work. Unless you have trouble with math, it shouldn't be too hard.

Modern tools for things like CPLDs and FPGAs mean you can get by with doing the hardware rather like software. VHDL or Verilog permits making hardware using languages along the lines of Java/C++/C# in terms of complexity. Knowing how to use boolean math and how the gates work is still handy, but not nearly as critical.

Okay, cool. I'll look into those classes for next semester, thanks. FraGag also sent me a Logisim file that helped clear up a few other things. Anyway thanks again!

This post has been edited by Andlabs: 01 June 2013 - 04:12 PM

[Andlabs]

Sorry for the quick double post but I'm still b it confused now: I'm now occasionally winding up in a situation where my monitor is trying to send data but the emulator thread is trying to pulse clk1. I immediately see two possibilities: either the monitor is too slow or I'm not pulling rdy at the right time... as this is all after REF "B". I had the clocks sending on demand (chiploop() in the second link) but that just caused everything to hang up for some reason; now it sends the clock pulse as soon as the node is changed... unless I should change it back and see what's wrong. Any ideas? Thanks.

[Andlabs]

New hypothesis: is it possible that my monitor code is just too slow? That is, must I guarantee that everything my external devices do will always run between master clock ticks? Since the only thing that would cause the deadlock of the chip sending a clk1 and the monitor sending to the data bus at the same time would be if a clk0 tick happened while in the middle of the monitor code loop. If so I'm not entirely sure what will happen when I expand this to cover other devices...

I also got this suggestion from #go-nuts; not sure if it would help

Quote

[19:39] <|Craig|> pietro10: I'd think a bool would be a better model of a pin than a channel. Maybe you could let things subscribe to get notified of changes (or maybe just rising or falling edges) via channels, but thats one channel per subscriber, not one channel per pin

This post has been edited by Andlabs: 05 June 2013 - 08:54 PM

[Chilly Willy]

Look at your pseudo-code again...

Quote

Wait for clk2 to go low (REF "A")
Read the address bus, RW, and SYNC

First off, REF "A" is clk1 high, not clk2 low. The difference is TD in the datasheet.
Second, once you find REF "A", you have TADS time before the address becomes valid, and
TSYNC time before SYNC is valid. It's possible your monitor code is too fast. You need to
pay much more attention to the cycle timing in the diagrams. Too fast or too slow and
you'll have never interface to the CPU. All those times in the diagram are VITAL. The datasheet
will give you the max and min values for the clock rate. MEET THEM!!