Thank you

In Digital, you can implement ICs as Digital files, and include them in higher level circuits. They appear in the Custom menu if they are saved next to your current file. I recommend watching rj45's series to learn more about it https://www.youtube.com/playlist?list=P ... I7pCWsy1AO



I believe you can also write external components in VHDL and Verilog, though the documentation is scarce and I have never tried it myself

_________________
BB816 Computer YouTube series

Thanks, I'll take a look when I'm back again. I'm in the middle of nowhere at the moment...(it's a hard life )

I suspect Verilog is a bit too low level for what I'm trying to do (ideally I need a language like C++ or Java) but I'll poke around in Digital again and see what I can see.

AndrewP, I really like your eight overlapping clock phases which seamlessly switch between two clock speeds. I briefly spent time doodling 4-10 phase schemes but failed to find anything worthwhile. Anyhow, I have a minor optimization which may reduce size and cost. If using 4 bits or less of 74x374 or 74x574, it is possible to use 74x161 in a non-counting configuration. Likewise, if using 4 bits or less of 74x373 or 74x573, it is possible to use 74x157 in a loopback configuration. I learned such devious tricks from Dr Jefyll.

I'm very impressed that you got four cores to share one memory bank. Most people achieve two cores and no further. I got beyond two but the case is restricted to the point that it is probably worthless.

If multi-media is required, for example 48kHz audio and 25.175MHz video, then dual port RAM is highly desirable. Agumander had great success with video blitting and Turing complete audio over dual port RAM. In the general case, cores with dual port RAM may be arranged as an arbitrarily deep tree such that one window of RAM with a fixed address is up-stream and one bank switched window is down-stream to each subordinate core. This arrangement requires the smallest memory allocations for communication and allows the fastest block copying when data is passed through. Furthermore, specialist cores may be compute only or have nothing beyond a DAC shadowed by RAM. A core may be paused, poked or interrupted and therefore no ROM or I/O is required. This allows discrete specialist cores to run above 30MHz while the root node (with all miscellaneous I/O) may be much slower.

If you have intense tasks and don't care about communication overhead, it is possible to serialize read or write operations over 24 clock cycles or more. This allows 32 or more cores to be wired to one window of memory; optionally with atomic locking. This is an extension of discrete circuitry for double clocked Quad SPI over 2^N+1 clock cycles. It is preferable for each core to have small FPGA due to the complexity of the logic. However, FPGA may also perform specialist tasks such as FPU or encryption.

The case most likely to interest AndrewP is the general, symmetric, high bandwidth option. If you want fast, cheap cores with fast communication, try a chequer-board configuration where adjacent cores run on opposite phases. Unfortunately, this arrangement does not have any unified view of memory. Each pocket of memory is local to one core or shared with one adjacent core. To prevent address glitches which come from sequential writes across two clock phases, two SRAM chips are wired in a cross-over configuration. Any given RAM chip in the cross-over configuration receives writes from one core only. Furthermore, atomic locking can be skipped because each core shadow writes to a read-only window. When only one party can write, the locks are redundant. An optional return path allows full-duplex communication using one region of memory. However, this is not general purpose read/write memory. The semantics are deliberately broken to implement communication between cores. To reduce size and cost, [url=file:///media/trisquel/C9CE-889C/20220326/in/Tech/6502/viewtopic.php?f=4&t=5805]50 cent skinny DIP RAM[/url] may be chip stacked.

Unfortunately, 2KB window between cores is extremely cramped if it is configured as, for example, seven 255 byte buffers plus pointers. However, four (or more) larger buffers consume too much of a 16 bit address-space. Therefore, large regions of 65816 address-space may be highly desirable for communication. This is a more onerous requirement than a tree of dual port RAM where the root node has one banked window into shared memory and leaf nodes may have a partially decoded window which fills the address-space.

At present, I feel quite stupid because I tried to tie everything to a central, two phase clock stretching unit. Firstly, this has scaling problems. Secondly, AndrewP shows that it is completely redundant because:

• Local RAM is never clock stretched.
• Shared RAM may be the only shared resource and clock stretching may be minimal, if any.

I think you've got the edge case absolutely correct. With 2:1 clock speeds, you only require a nudge of one phase (viewed from the fast clock) or one cycle (viewed from the slow clock) to re-join the slower collective. The tricky part is when to apply the change of speed. However, there is probably some grace if an absolute address is strobed to switch speed because the surrounding instruction and data cycles are (hopefully) unaffected by clock stretching. The exact phase is critical when executing from shared, clock stretched RAM. However, that case is guaranteed to fail if shared RAM is switched off.

I didn't try to solve a practical, restricted case. I tried to solve ridiculous, erroneous cases. For example, where one core spends 33 cycles on slow I/O and then another core attempts same from the same clock stretching hardware. Instead, it may be preferable for each core to have local I/O and local clock stretching. Actually, I'm a little disappointed that some symmetric I/O configurations are impossible. For example, two cores on opposite clock phases won't trivially share one 6522. If 6522 didn't have clock input, sequential writes across two phases would glitch. That's no different to RAM. However, reads wouldn't work either. Reads would glitch but there is another limitation. Historically, NMOS 65xx peripherals used the idle phase for charge pumping. They didn't have the speed or power to answer two cores.

This precludes a general SMP system where dozens of cores use one bank of RAM and all peripherals. This means one core cannot use the majority of the system's RAM. Likewise, it is more difficult for all cores saturate a network connection. Despite such limitations, I wonder if it is possible to fit two cores onto a 100mm*100mm board.



I'm interested in your answer. For me, it is most immediately intellectual curiosity. For you, it might make you more systemic with future projects. A project may be an outrageous success, mixed or a complete failure. Many of my best projects had a mixed outcome where some parts worked well, some was unknown and some failed. We often see this with hardware projects which require a few patch wires. If you never require patch wires then you are advancing too cautiously.



I quite like your SNES circuits and I am very impressed with your soldering. SNES protocol is a good test and SNES protocol can be practically extended to a range of input peripherals which includes keyboard and mouse.



Dang it! I bought four SNES joypads with the 9 pin D connector. I assumed that the socket would be easier to source and that the pins would vary less. Presumably, that's why you have an adapter board.



That's painfully slow. Make-A-Chip on ZX Spectrum could simulate 20 gate ULA and I presume that was written in BASIC on a system with the effective processing power of 6502 running at 300kHz.



I'm looking for KiCAD but betterer. Your requirements increase the scope by approximately 1/2 but it remains feasible.



I've found many limitations in KiCAD. Many of the inconsistencies between schematic editor and layout editor could be resolved by integrating them into one program. In particular, there would be no requirement to keep two inconsistent file formats synchronized.

Would you prefer to do simulation directly in a schematic editor which allows a true bus structure? Specifically, within one application, you would go directly from simulation to manual board layout.

Automated layout is computationally difficult and may preclude a self-hosting circuit CAD system. However, it may be feasible if the problem is sufficiently constrained.



Elephants have good memory but can you stack them?

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Thanks! It's all still simulated at the moment but I'm hopeful it will work in the real world. I suspect with less address decoding (and if I had better understanding of how SRAM works) that more cores could be added. Sometime... in the far future.

I wish! They're just way to expensive, even for little ones. And I'm probably going to be looking at around 1MB of graphics memory so I've had to use frame buffer flipping instead. I might have mentioned this but it is by far the most complicated circuit I've ever designed. And I thought it would be just be a multiplexer or two to get going. Oh poor naive me

I found your Cell Network Hardware thread incredibly interesting so thanks for the link. Though it was, in large part, why I've taken so long to respond; it was a lot to digest

I've never thought of (much less seen) an architecture like this. It's very cool but (and of course there's a but) it's too late into design for me. Everything I have is designed around a single main memory that's transparently accessible.

That's my hope. If I put in the time now I should be more productive in the future. Did I mention I just spent three days trying to represent a floating point number in text?! Sometimes that productivity thing seems to be far and away...

Thanks! That's much appreciated. I really wish the SNES protocol was the way keyboards and mouses had gone. I've simulated up a PS/2 circuit for a keyboard and mouse but not having the '816 be the master is a huge pain. Really, why can't we just have big shift registers on a single IC? Even better a 128bit shift register addressable over an 8bit port. That would be wonderful.

Kinda, I'm mostly assuming I'm going to have multiple versions of the PCB with all the circuitry on it and don't want to waste (or re-solder) connectors every time I make a change. I ended up buying 40 connectors off of Ebay because the postage to South Africa was the majority of the cost. Yay for living in the middle of nowhere!

Absolutely! but they develop compression problems towards the bottom

And this is going to have to be the end of part one of this reply or I may never hit send

After watching akohlbecker's video tutorials to episode 21, it is apparent to me that considerable time, effort and error can be reduced with a Digital/KiCAD import/export or conversion script. A common format for simulation, schematic and layout remains preferable. However, the minimal effort would be beneficial even if it is only used by 6502 Forum members.

SMP and NUMA are preferable for multi-core systems because a unified view of memory allows pointers to be consistent. However, this conflicts with the desirable constraint to work in a small address-space with small pointers. 16 bit or 24 bit SMP is a good choice and examples are rare.

With shared memory, we seem to have encountered the old adage:



Dual port memory is fast, highly reliable and allows sub-systems of any frequency to be spliced together. This is a particular boon for multi-media where, for example, 48 audio samples and 25175 video dots can be emitted every 1ms. However, dual port RAM isn't the cheapest option. Historically, dual port RAM has been an exotic component and I presume that dual port RAM will be highly susceptible to the chip shortage.

A cross-over memory configuration is a cheap, compact hack which can be chip stacked. However, it will definitely be more difficult to program. I am also unsure if read-modify-write has any useful semantic in a cross-over configuration.

A core which explicitly opts out of cluster synchronization is a very balanced solution. It isn't the cheapest and the explicit hint is incompatible with legacy binaries. However, it scales the furthest and is easiest to program. That has considerable merit.



I convince myself that I'm laying a foundation of skills and I'll get faster. However, I am concerned that I might be getting slower. I ghost wrote a Margolas particle simulator in six days (and this is directly relevant because it influenced a 65816 grid design and the cross-over memory configuration). More than a decade later, I wanted to re-create the Margolas particle simulator and my second attempt took 14 days; partly because I want to maintain the quirks of the first implementation.

Also, I'm impressed that you *only* spent three days on floating point text representation. I've previously spent two days deriving a constant for a hash function. I initially thought that 13 would be a good choice because it was used in an Atari ST magazine for pseudo-random number generation. 13 is also used in a hash in the Commodore Amiga filing system. I subsequently found that I required an odd multiplier which is less than 16, has two bits set and is co-prime with 256 (and 65536). The astute will note that 3, 5 and 9 meet this criteria. So, I present two days of software development, excluding documentation:



However, it was worthwhile. This hash function, running on a network client, allowed a stateless server to maintain more than 2^17 network connections while using less than 1MB for program and data and less than 3.7MB for network buffers. Essentially, with a suitably rigged network protocol, it is possible for 65816 to achieve this feat. A quad SMP 65816 design may make this four times faster.



I'm fairly certain that PS/2 protocol is deliberate obfuscation. When I first encountered PS/2 protocol, I wrongly assumed that it was bi-directional UART. Indeed, why does a keyboard protocol have to be more complex than a teletype?

I've considered ridiculously long chains of shift registers. For example, I wanted to make a quad 256 bit cell network card with 3x over-sampling on receive. That's 1024 shift register bits (128 chips) per duplex channel. After this, 128, 192 or 256 bits for keyboard looks extremely modest. With some multiplexing, I eventually reduced this down six chips: one 4 bit counter, two de-multiplexers and three 8 bit shift registers. This allows a 16*16 switch matrix to be sent in rows. This adds 50% overhead but I believe that it is faster and more reliable than ADB. It also gives me hope to simplify (or unify) video, audio and network.



That's an astoundingly good comeback and I really wasn't expecting such wit.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

We - here in SA -have been suffering from load shedding again but the power only gets turned off in the evening 'cause winter and that's when everyone turns heaters on. Sadly this makes powered free time a bit of premium and that's slowed everything down.

I did manage to wire up some LEDs, so that was fun

On the Logisim side of things the decision to move away from using it was the right one. Unfortunately Logisim Evolution is not being well maintained to the point where I find new versions unusable. The performance has tanked, saving is intermittently broken (kind of a huge problem), custom circuit display no longer works and I'm still a bit miffed about my pull request being accepted and then overwritten by someone else who didn't take the time to merge properly. Logisim Evolution has also been moved to bleeding edge versions of software that don't play nicely with other development I do.

With all of that said a logic simulation editor is important. Logisim showed me I had a lot of it'll-just-work wishful thinking when I first started drawing up my little homebrew computer.

Digital is starting to look more appealing; I had a dig through its source and it seems clean and well structured. I'm still attempting to write my own - even if it's only used by myself. Avoiding the effort and error of converting logical simulation layouts to KiCad is well worth it. If someone else on this forum finds it useful that'd would be awesome. Baby steps first though.

Funnily enough years ago I was working on a system that used multiple Xeon processors in a NUMA configuration. The system we were trying to build was such a bad fit for NUMA that in the end we disabled all but one the processors and got better, more consistent performance. Anecdotally applications have to be built with NUMA and that makes retrofitting old applications hard. Anecdotes aside a unified view of memory is a huge win for programming, be that SMP or NUMA.

Dual port memory would solve so many of my async problems. And so simply. But it's just SO expensive that I can't justify using it. To put it in perspective: I can buy 13 LCD display for the cost of just 3 tiny 1KB dual port ICs. Or even more in perspective:I could buy 23 32KB SRAMs for the price of a single 1KB dual port SRAM.

(Why do I have 13 LCD character displays sitting in my cart? I have no idea).

The solution I have found (but not tested at high frequencies) is to have two SRAMS that I can explicitly trigger a swap between. i.e. The MPU writes to memory A while the video DAC reads from memory B and then during a know phase where the video DAC isn't using memory the MPU triggers a swap. It's quite a few ICs (multiplexers and transceivers etc...) to allow the 'swap' - I posted a simpl'ish implementation somewhere else in this forum.

When I was young it seemed I could bash out a game or whatnot in a couple of days but honestly they were unmaintainable piles of crap that I never truly finished. Now I've been around the block a few times I find it takes me ages to write anything. But. I've also discovered that I can leave a project for a few years and then pick it up again without much effort because I put all that time into making it consistent and maintainable. Personally I find I am getting slower as I get older. Most of that is because I am more thorough in how I do things. Not all of it though. I have realised I could concentrate more deeply when I was younger; that's just life I suppose.

Your intermittent power prompted me to buy a small solar panel. I will go through the calculation separately but 100mm*100mm is a convenient size which can indefinitely power 100kHz CMOS 6502 and passive LCD.

I am highly unimpressed about Logisim Evolution's inability to serialize data. That alone is a deal-breaker. I wonder if some open source projects are deliberately sabotaged. It would require less than 0.01% of a large competitor's turnover. That's less than USD100000 per billion - and it would be a tax write-off. Indeed, it is almost diligent to maximize shareholder value through competitor sabotage.

Thank you for reminding me about the hardware double buffering trick. I've sketched similar but I'm ambivalent about it. Dual port RAM is more expensive than mono port RAM, tri-state buffers and the additional board area. However, it remains unwieldy for discrete implementation and opportunities to switch buffers are coarse. It seems like a great trick to switch two buffers at 60Hz or similar and run either buffer at either frequency. However, hardware construction is not the only limitation.

I have three use cases for hardware double buffering and only one is satisfied. The first would be described in the DTACK Grounded newsletter as "rock shooting". That's a derogatory reference to Asteroids or similar action game. In this case, there are never enough clock cycles to read back from screen because if you have enough clock cycles then you can have a bigger screen. This case works absolutely fine. However, hardware double buffering is horrible for full screen video or GUI. In the case of GUI, everything has to be drawn twice. In the case of full screen video, motion deltas will be between even frames only or odd frames only. Even if the display progressive, the codec becomes interlace. That increases the size of deltas, increases storage transfer time and increases the risk that rendering takes too much time.

We're trying to decouple processor write speed from display read speed - without creating onerous constraints on codecs or GUI. jfoucher wanted to place one optional display in a separate clock domain and I suggested a scheme which constantly hammers the last write from the processor. Unfortunately, this also has limitations. A simplistic implementation may have a Nyquist sampling limit. For example, 14MHz 6502 or block copy from 65816 may work without problem. However, 16 bit write from 14MHz 65816 to 25.175MHz display may partially fail. This is an annoying corner case and extra circuitry for 65816 is likely to be insufficient for a hypothetical 65832. There is a common pattern here: draw everything twice or draw everything slowly so it can be sampled twice.

We also have the problem that reads require clock stretching whereas writes don't require clock stretching. However, we may have less than 30ns to assert a clock stretching signal - which should be the intersection of an active high read signal and an active low address strobe. So, we either have write-only display, read/write display with hobbled write speed or an attempt to implement high speed, high energy circuitry. It is another corner case.

Hardware double buffering avoids snow, tear and clock stretching. These are all huge advantages. However, hardware double buffering also eliminates single frame motion deltas. That dis-advantage almost makes it preferable to have snow or tear. There is no good answer here. Discrete schemes which lock processor and display have dis-advantages. Discrete schemes which don't lock processor and display have dis-advantages. Dual port RAM has dis-advantages. Hardware double buffering has dis-advantages. With an impossibly large FPGA and pipelined DRAM, it is worthwhile to double buffer at the granularity of one scanline - and that also has dis-advantages. Interleaved processor/video is the quickest win but it also creates the largest technical debt. For example, Commodore 64 compatibility starting with Commodore's own C128 but also including C-One, MEGA65 and VICE. And Apple II cycle compatibility across video and floppy interface which led to 65816's emulation mode. It may be desirable to have a budget, one chip, interleaved scheme which is register compatible with a different implementation. In the case of compatibility with hardware double buffering, strobing a buffer swap may have no effect. In the case of asynchronous or pipelined schemes, a window of memory may be selected without concern about implementation detail.

There is similar over-choice at a lower level. Again, there is no universal answer. For example, it may be desirable to display 1920 bits (240 bytes) using 8 bit binary counter. This count may include or exclude porch and horizontal sync pulse. Alternatively, it may be desirable to use the co-primes of 4 bit counter restricted to 15 values and unrestricted 4 bit counter. Again, counting may include or exclude additional periods. Co-primes have the least latency and this may reduce fringing if other circuitry does not hold steady output. However, it may be cumbersome to populate or scroll each line in hardware or software. Co-primes complicate upward compatibility. Going from 2K to 4K to 8K is trivial. Just add one bit to one counter. However, 6K requires a different strategy. That's hugely important if you want to use the same type of circuit for high speed networking and use the least RAM for a given packet size.

I will answer separately about productivity; possibly on anycpu.org because it isn't specific to 6502. Regardless, I am concerned that new categories of smaller computer, the typical unstructured and surreptitious advancement of programming skill and project autonomy/complexity all collide and lead to professional burn-out. Career longevity may not be determined by unwillingness to chase the next gold-rush or the inability to mold staff with no dependants. It may be a desire for thoroughness and consistence rather than bodging an answer through ignorance or carelessness.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Perhaps you're already aware, but specialized multiplexers are available for this purpose. Here's some TI doc (and maybe there are offerings from other manufacturers, too). Compared with doing things "the hard way," the Bus Exchange function shrinks the pin count substantially.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

that heavily depends on your standards.
if you don't mind buying second hand you can get some really cheap chips.
https://www.utsource.net/de/itm/p/532049.html (PLCC-68, 5V, 55ns, 8kB DP-RAM for around ~2.70 USD per chip)
I bought 10 of those and all of them seem to work perfectly fine.
that's also the site where i got my 10 ATF1508's from for pretty much the same price per chip.

Same here, I bought used atf1508 equivalent, EPM7128SLC84, from UTSource for about $2.50 each. Purchased about 50 of them and so far so good. Used 4Kx8 dual port RAM, IDT71342, is also about $2.50 each. I used the dual port RAM so much in my designs, I’ve purchased at least 100 and they all work fine.
Bill

Thanks! That sent me on a learning spree... and to a section of Mouser I've never visited before Digital Bus Switch ICs. Although I may be sternly eyeballed if I order another box of ICs

Standards what now?
I've harassed utsource quite a bit* trying to find dual port SRAM but with no luck. I haven't tried anything with access times over 20ns so that will need to be my next port of call.

* Looks like I've tried to find 7140LA20JG8, 7140LA20JG, 7140LA20PF, 7140LA20JG8, 7140LA20PF8 and 7140LA20J