polpo

In my experience with parallel FRAM, it’s as fast as SRAM and is a drop in replacement with the same timing.

A lot of folks have replaced battery backed SRAM with FRAM on game consoles.

This is a framework for building things that run on DOS (yes, that means running JavaScript on DOS). If what you’re running DOS on has a working parallel port, DOjS can use it.

If all you want is text chat with no shared history, sure IRC is fine. But think about these features that the chat apps bring:

Search: half-remember some conversation from months/years ago? It's right there, in the app.

Persistent history: onboarding a new employee? All of the company's past communication is there to browse and search (see above point).

Inline file attachments: need to share a small file or a screenshot with someone? Drag it into the app and they can get it at their leisure. No need to mess around with DCC send or uploading to Google Drive and sharing a link, it's right there.

All of these could be solved with IRC (in fact, Slack was initially built around IRC) but they require extra infrastructure and tooling and development to make it seamless, and that takes extra development and hosting costs.

The grandparent poster may be talking about ATSC 3.0 which has been rolling out for a while. H.265 at a reported 28-36Mbps is nothing to sneeze at!

I don’t know where he got his, but last August there was one on shopgoodwill.com. I was tipped to it on a small retrocomputing Discord server but I stupidly forgot to bid on it. There were only 2 bids and whoever won the auction only paid $26 for it.

And the other item the seller had was a Taylor Swift concert ticket that used the wrong font. There’s definitely a pattern there. https://social.panic.com/@cabel/112452964691814590

It’s interesting to note that the WiFi on the PicoMEM is based on code from yyzkevin originally from his PCMCIA project. And the PicoMEM uses PSRAM code from my PicoGUS project. And then PicoGUS uses Sound Blaster code from yyzkevin. And now I’m getting inspiration from how PicoMEM does address decoding. And so on and so on… This is a pretty cool little open source community we’ve created around the RP2040, cross-pollinating each others’ projects.

It could happen at any time to the 65C02. The Z80 was only EOLed a few weeks ago because they couldn’t get wafers from their fab any more. Any chip on an old process is at risk of this.

Thanks for the link – just opened an issue concerning the font weight and text color on the site.

I'm going to push back on the comment in the article about the build system being overkill. While "tiny" is a relative term, not all projects built for the RP2040 are tiny – my PicoGUS project relies on several external libraries and being able to bring them in via CMake is pretty great. Also while the Pico itself is fixed hardware, the SDK targets many other boards built on the RP2040. The Raspberry Pi team definitely have things architected for future versions of the microcontroller as well as on-host testing of the SDK.

I sure hope mainline Vim isn't dead. I keep trying NeoVim but I prefer using Vim in a GUI and no NeoVim GUI I've found has the level of polish that MacVim [1] has. VimR [2] comes close but keep finding myself going back to MacVim.

[1] https://macvim.org/ [2] https://github.com/qvacua/vimr

It runs natively, not under emulation, and can integrate with any other build system that you have running natively. Granted, if you're building DOS apps, the overhead of running the x64 version of OpenWatcom in emulation probably isn't bad as it's still orders of magnitude faster than it was back in the day.

I also do retro development on an Apple Silicon device, and like the author I built OpenWatcom so I could run it natively. I have it tied into the build system for the rest of my project and it works great.

I really don't understand why chip resellers re-mark chips like this. It's always obvious and it gives me the idea that they have something to hide. I've paid more for obviously used chips that I can tell are genuine than "new"/"refurbished" examples like the ones in this article.

I love the AY-3-8910 and I've bought chips that were remarked in this fashion, fortunately they all worked ok and sound like the real deal.

I did this in college in the late 90s/early 00s. It was fun and I could keep up but ultimately it was a dumb flex and I didn’t retain the info any better. I’m glad I stopped. I still did my homework exercises in LaTeX but that was sort of an ADHD-driven yak shaving/procrastination exercise.

I love the AY-3-8910, can't wait to see how this turns out.

I really don't understand why chip resellers re-mark chips like this. It's always obvious and it gives me the idea that they have something to hide. I've paid more for obviously used chips that I can tell are genuine than "new"/"refurbished" examples like the ones in this article.

The person who imaged the disks commented on this video exploring 86-DOS 0.11: https://www.youtube.com/watch?v=Zd7T5euID1E

(It's a neat video by the way – he shows how 86-DOS would be used in that state back then by creating a Z80 "Hello World" program in CP-M, copying it over with RDCPM, translating it to 8086 assembly with TRANS, tweaking the source with EDLIN, assembling with ASM and HEX2BIN, and running it.)

Given that Boeing currently has to ship planes to Europe with 25 hours of recording capacity, and that this plane is only a few months old, I'd guess it already has 25 hours of capacity and it's artificially limited to 2 because it was shipped to the US, due to the opposition from pilot's unions.

Gunpei Yokoi's ethos of "lateral thinking with withered technology" [1] has been an guiding principle within Nintendo since the Game & Watch days: to use "seasoned" or otherwise imperfect technology in creative ways. Using a broken SoC that they probably got a great deal on that still fits their needs fits perfectly in that mindset.

[1] https://medium.com/@adamagb/nintendo-s-little-known-product-...

Way back when the Nintendo Wii was brand new and hard to find, I wrote a script to scrape Target.com for store inventory and notify me if a nearby store restocked. A few years after that I revamped it to check on inventory for newly released iPad models. I put the code up on GitHub [1] and the CTO for a company that had large-scale store inventory checking as part of their product emailed me out of the blue after seeing my repository. A little while later, I replied back, interviewed and got a pretty good job offer out of it. I wound up not taking the offer, but in hindsight I probably should have.

[1] https://github.com/polpo/ipad-target.py

There are guardrails around access to the clipboard (and the post talks about the circumstances around it) but this exploit takes advantage of the fact that simply selecting text on X11 puts it in the primary selection buffer. The code just tells Firefox to select the text.

Just looked at the Wolf3D source (https://github.com/id-Software/wolf3d/tree/master/WOLFSRC) - it uses VGA in unchained mode but still at 320x200. So not exactly Mode X, but "Mode Y".

In St. Louis most stations are K but there are a few Ws.

Because the footage isn't "real" and isn't through the lens from the perspective of the player. Actual through-the-lens video I've seen is constrained to the retroreflective surface. Example: https://www.youtube.com/watch?v=wKjr__J-ego

I suppose there's a chance that something that is within the confines of the play mat from the player's perspective could appear outside of it to a theoretical outside observer, so they made their marketing reels have stuff appearing outside of the retroreflective mat.

It's projection and the gameboard is a retroreflector. Their about page goes into pretty good detail about how it works: https://www.tiltfive.com/the-system

Reminds me of Apple’s Chalkboard font, which basically fixes everything that’s off putting about Comic Sans while still being casual and child-like: http://www.identifont.com/differences?first=Chalkboard&secon...

More than 32 instructions per PIO block: my main current project (PicoGUS) uses 32 instructions on one PIO block and 31 on the other to handle ISA IO, ISA DMA, I2S audio out, and SPI PSRAM access. Having more would let me cut a few less corners in how ISA is handled.

More/more flexible PIO instructions: branching is very limited, you can only arbitrarily SET up to 5 pins or pindirs at once (increasing to 8 would be a godsend), stalling with a sideset repeatedly executes the sideset, etc... I could go on.

Memory mapped PSRAM: I made a library to assist with accessing SPI PSRAM but it's still just functions to get/set groups of bytes. An intelligent cache around it would also mitigate the much higher latency of accessing PSRAM as well.

More SRAM: everyone can always use more RAM!

More GPIOs: everyone can always use more GPIOs!

Given that there is a whole publicly traded company that does ARM SoC interconnect as their bread and butter (Arteris IP) and they and their stock price seem to be doing OK is an indication that it’s still allowed.

Pretty standard in that they were included in what you sign when you start a job? Or standard that they were actually enforced? When I was in California in the mid 00s I worked at several jobs that gave me a noncompete to sign when I started, and I knew then that they were unenforceable.

We are legion! Love my NextLight.

Yes, to switch the card being emulated, you can flash new firmware images directly from DOS using the pgusinit.exe program that ships in the release package. It takes about 5 seconds to load the firmware and the new emulation is available to use right away without needing to reboot the machine.

Longer-term, I'd like to have multiple cores available in one firmware image for the ability to instantly enable/disable them. All code runs from RAM instead of flash for speed, so that's a potential limitation on the number of cores that can be loaded simultaneously.