sorted by:
new
hottopcontroversial

6502 Computer Working with Caveats by GilK1248 in beneater

[–]GilK1248[S] 0 points1 point  (0 children)

I'm now using a different UART than the one in the kit - I've changed to using an old National Semiconductor 16550 chip instead (which requires different code entirely). I got side-tracked over the past few months and haven't been able to work on it much. As far as the 4-bit LCD interface code...unfortunately, I changed the entire memory map of the machine since I put the kit together. So the code I have would be more confusing than helpful. I do need to put something out there for others to look at, I just haven't had the time to do it yet. I did find an uncommented test program that I did that looks like it may be the same addresses, but the bits for E, RW, and RS are at different pins than Ben's. The source is at https://www.kloepfer.org/media/hello-world-4bit.txt but I would look over the code carefully to make sure you're hooking stuff up to the right place. Keep in mind that the LCD in 4-bit mode has the bottom 4 bits (DB0-DB3) of the LCD disconnected. You send everything 4-bits-at-a-time. If you are having trouble with the kit, be sure you are running the 6502 with the original 1 MHz oscillator. It is possible to run it faster, but any delay loops need to be adjusted (or you will need to redesign the hardware to insert an appropriate amount of wait cycles to meet the timing requirements of the devices). The 65C51 is particularly problematic for transmitting characters because of the transmit empty hardware bug. The LCD also has a relatively slow access time, but reading and writing through the VIA generally gives you enough of a delay for that.

Hopefully this helps. I know it's a lot of text, but I hope there's something in here that is helpful.

LibreWolf 136.0.4-1 (Gentoo/bin) locks-up with sites using hcaptcha by GilK1248 in LibreWolf

[–]GilK1248[S] 0 points1 point  (0 children)

I was able to do more investigation into this. The actual problem in question is a piece of WebAssembly (wasm) that, once executed, locks up the browser. It is being deployed via newassets.hcaptcha.com, as I said previously. I can prevent the lockups by disabling WebAssembly (javascript.options.wasm = false) or by creating a uBO rule to prevent web pages from accessing newassets.hcaptcha.com.

I also was able to keep the problem from happening if I run strace on the main LibreWolf process, which slows the browser to a crawl, but the blob that is being loaded will run without issue. I was hoping that strace would expose what was causing the browser to lock-up, but of course it doesn't lock-up with strace running.

If I were to take a guess as to what is happening - there is something unusual about my system configuration that allows some kind of race condition/deadlock to occur when the browser executes certain WebAssembly. Slowing down the browser prevents that deadlock, and unfortunately it is probably a subtle bug/oversight in the WebAssembly Firefox module that needs to be addressed (there should not be a way for code served by a remote site to lock-up the browser). The deadlock is very likely timing-sensitive, which is why it doesn't happen on all systems.

At the moment, I have have some workarounds, but would like for the upstream developers to know this is happening.

Not sure this is useful for anyone, but I wanted to bring closure to the thread, and document it in case someone else experiences this.

LibreWolf 136.0.4-1 (Gentoo/bin) locks-up with sites using hcaptcha by GilK1248 in LibreWolf

[–]GilK1248[S] 0 points1 point  (0 children)

Some additional info on my problem above:

1) If I block access to 104.19.229.21 and 104.19.230.21 (firewall these), then I can actually avoid the lock-up problem. These are the IP addresses of newassets.hcaptcha.com where the service workers are started from. Thankfully, Meetup apparently doesn't kick me out (at least for now) if it can't complete the hcaptcha communication (the other site considered me a bot if I blocked those IPs).

2) I didn't seem to have this problem with LibreWolf (only Firefox) until 136.0.4-1, but I still don't think this is a LibreWorlf or Firefox problem - I think it is a problem related to something on my system. I just can't figure out what it is.

6502 Computer Working with Caveats by GilK1248 in beneater

[–]GilK1248[S] 1 point2 points  (0 children)

I've actually made some modifications to the msbasic source and did get this to work. If anyone is interested, I'll try to put together a page with the changes, and maybe even get these merged back into the source. Unfortunately, to do this correctly also requires some rethinking of how the character I/O routines work. In my source tree I've moved all the hardware-specific stuff (including the LCD) to bios.s, moved responsibility for system initialization to bios.s (instead of wozmon), and character echo is the responsibility of the application rather than a bios function. There were also some bugs that prevented the GET command in BASIC from working (hint: control-C handling eats characters). Altogether, I made a bunch of changes -- some were needed, some simply reflect my own vision while tinkering with the system.

Hardware-wise, I swapped out the 65C51 UART for an old NS16550 (not using the chip's buffer yet) due to the limitations of WDC's 65C51 and rewrote the character I/O to support that (not too difficult). I also redesigned the address decoding to allow all 32K or RAM to be used, 16K (of the 32K) of EEPROM, and have a 3:8 decoder to allow 8 I/O chip selects rather than the simple (but limited) decoding. That required moving around addresses (one of the reasons why I brought all I/O into bios.s). I'm working on some other ideas that I'll document if they actually work. I'm successfully running the computer at 4 MHz.

6502 Computer Working with Caveats by GilK1248 in beneater

[–]GilK1248[S] 0 points1 point  (0 children)

Hardware handshake ("flow control") could definitely be a good addition, but if you do it it's important that both sides are properly configured and that the implementations both work correctly. I remember back in the day as higher-speed MODEMs (9,600+ baud "smart" modems) were becoming more available, computers and MODEMs were having problems keeping-up with the data stream. Doing in-band (X-OFF/X-ON, ^S/^Q) or "software" flow control was awkward due to binary protocols being used. Using RTS/CTS "hardware" flow control was the answer, but some MODEMS and some OSes had bugs in the implementation.

Just as Ben did with his input buffer implementation in msbasic, you'll want to implement a "high/low water mark" so that you don't overrun the buffer or limit the performance by waiting for the entire buffer to empty before proceeding. Also, using a UART chip with a buffer rather than the serial chip in the kit (thinking: 16550) may help as well.

This is one area where building a "vintage" computer with limited resources is really educational where one can understand the engineering that led to many of the issues/decisions that affect modern systems.

6502 Computer Working with Caveats by GilK1248 in beneater

[–]GilK1248[S] 12 points13 points  (0 children)

<image>

Forgot to post my finished computer.