Commander X16

2 hours ago, Scott Robison said:

Each new page stored a reference to the previous page

That's an impressively bad design.

HW-accelerated heap-management -> heapRAM = He-RAM.

By the power of hardware.... HE-RAM! ... I--- HAVE--- THE GARBAAAAAGE!!!!

9 minutes ago, SlithyMatt said:

That's an impressively bad design.

It was just a thoughtless choice. "We don't have to worry about objects, allocate all we want, the system will collect them later!" without the corresponding "We need to make sure we forget all references to objects at *some point*." The bandaid I applied to that was to only keep the most recent X pages to give the instant back button for the majority of cases, then back becomes a home button if there are no previous pages.

To be fair to that programmer: he was young, and he was bright, he just had been tasked with implementing something quickly, and thoroughly analyzing the approach fell by the wayside. I wish I had a nickel for every time I was in a similar circumstance!

6 minutes ago, SlithyMatt said:

That's an impressively bad design.

Why store each entire page web-cache style?  I''m pretty sure only storing the file location and/or previous answers to questions would have been sufficient.  Did the kiosk also feature artificial intelligence routines that required the user to input entire answers to essay questions?

We had a much bigger problem, actually, that was the fault of no one in our office. Someone noticed that if you left the kiosk running long enough (after I fixed the memory starvation problem due to crisis of infinite page references), the screen stopped refreshing correctly. It didn't crash, but things like album art (it was a self serve media sales platform) wouldn't be drawn correctly.

In analyzing it, I noticed in task manager that the handle count for the process was climbing and climbing and climbing, and when it finally hit the 10,000 handle limit imposed by XP it couldn't allocate more handles. So we had a resource leak. But we didn't do anything directly with handles.

As it turns out, there was a bug in a C# implementation that would duplicate a region handle, do some work with it, then never discard the handle. The fix I implemented was to just rewrite that C# method and change all calls from the original to my bespoke version. It was not a routine that would be often used, but we did use it ... a lot!

3 minutes ago, Kalvan said:

Why store each entire page web-cache style?  I''m pretty sure only storing the file location and/or previous answers to questions would have been sufficient.  Did the kiosk also feature artificial intelligence routines that required the user to input entire answers to essay questions?

As I wrote in another reply that you might not have seen yet, it was just not having enough time to do the design and think through the issues. This was a simple implementation and not a problem if you only had a few pages, and the back button worked instantly. But the kiosk did have some screens with potentially long input fields (not quite essay questions) that a user would use a touch screen keyboard to enter search criteria to wade through multiple terabytes of content trying to find what they wanted.

Also learned at that job (and it would have been obvious if social media had been a big thing yet, but it was really just getting started): there are lots of bad spellers out there, so many times people would type in some search criteria and misspell names and not find what they wanted, even though we had it. It is complicated by the fact that many artists use creative or leet spelling (P!nk for example) which just doesn't match pink. So I wound up implementing a fuzzy search module that would take the words typed and match them to all the words in our dictionary. It meant more time at kiosk start to build tables that could be reused through the run of the application, but people actually started finding what they wanted because matches were sorted by edit distance. There might be a few exact matches at the top (legitimate matches for pink that are not p!nk) but then just below that would be p!nk since it had an edit distance of one and thus was a better match than say "sinatra".

Application development is like 15% programming the application itself, and 85% error handling.

On 7/26/2021 at 5:25 AM, Guybrush said:

Two 6502's could also run on opposite phases of the clock, like 6510 and VIC-II run in the C64 and access memory without DMA or dual-port RAM. If they need to signal each other, they could use a VIA to signal interrupts. I'm not sure if both could access the same hardware (except memory, of course) because the timings might be a problem, but if you dedicate one of them to handle I/O, sound or video, then they don't have to both access all of the hardware.

They should still have their own RAM in part of their address space ... but this could definitely be used for communication between the CPU's. If one are of the common RAM space is allocated to W#1 and R#2 and another is allocated to W#2 and R#1, you get the effect of using dual port RAM for channels without the expense of dual port RAM.

But there is no need for dual-port RAM if the processors run on opposite phases of the system clock since memory accesses never occur at the same time, they are interleaved. There's also no need for dedicated RAM (apart from zero and stack pages), it would only complicate loading the data and code for the second processor. Let the programmers use RAM as they please.

3 hours ago, Guybrush said:

But there is no need for dual-port RAM if the processors run on opposite phases of the system clock since memory accesses never occur at the same time, they are interleaved. There's also no need for dedicated RAM (apart from zero and stack pages), it would only complicate loading the data and code for the second processor. Let the programmers use RAM as they please.

I think the only point is that some tasks will work better if the individual CPUs have access to private RAM that cannot be overwritten (deliberately or otherwise) by the other CPU. One memory map that comes to mind would divide the address space into two 32K chunks. The first half is private to a CPU (so each CPU gets its own zero page and stack; the stack in particular you do not want to share directly between these CPUs!). The second half is shared address space. Each bank can contain any combination of RAM / IO / ROM desired, including an ability to do bank switching to give access to even more public or private RAM / ROM.

Ultimately it doesn't have to be an even 32K split, but I think at minimum you'd want the private stacks, and probably private ZP, and perhaps even another page or two of private non-shared space.