Looking for 4 program ideas

[ashtons]

Greetings!

Working on a portable homebrew computer project and I am trying to figure out a few things. One thing is the final four programs that will be put in the program ROM. The program ROM, or pROM, is a 128k ROM banked into an 8k area, allowing for 16 different built-in programs. I've already figured out what the first 12 should be, but I can't think of anything for the last 4. That's why I'm posting this, as I'm hoping I could get some ideas from everyone else.

Here's the main restricting factors: the program will need to fit into 8k, the computer will have 32k of RAM, and the display is going to be a NHD-240128WG-ATFH-VZ# (240px by 128px, text or graphics). There will be serial (W65C51N) and parallel (W65C22S) ports - though the parallel port is really more like a commodore user port in terms of pinout.

[BigDumbDinosaur]

ashtons wrote:

There will be serial (W65C51N) and parallel (W65C22S) ports - though the parallel port is really more like a commodore user port in terms of pinout.

You might want to consider an alternative to the 65C51. The WDC version has a significant hardware bug on the transmit side (the stuck TxD ready bit) which needs a workaround in the driver. The stuck bit prevents the use of interrupt-driven code and requires a pacing mechanism to avoid data corruption. We have discussion on this around here.

If you don't plan to clock this machine too fast you may be better off using the Rockwell 65C51, which doesn't have any hardware errata. Or, use some other UART, e.g., the NXP 28L92.

[BigEd]

Welcome!

I'd be interested to know what the first 12 programs are.

Here are some ideas, depending a bit on the peripherals you'd have:
- a calculator
- an alarm clock
- a simon type game
- a lunar landing type game
- a cows and bulls type game
- a basic interpreter (perhaps tinybasic)
- a VTL interpreter
- some kind of rolling demo as a crowd-pleaser

[Dr Jefyll]

ashtons wrote:

I've already figured out what the first 12 should be, but I can't think of anything for the last 4.

Maybe you should forget about this problem (?) for now, and concentrate instead on getting the machine built and working. Then later (when you've had a chance to play with the first 12 programs) you'll have a better idea of what to do next.

Just a suggestion. Have fun and keep us posted!

-- Jeff

[barrym95838]

ashtons wrote:

... the display is going to be a NHD-240128WG-ATFH-VZ# (240px by 128px, text or graphics) ...

Sounds like a potential candidate for a Tetris port.

[IamRob]

Many languages will fit into 8k of ROM. To name a few: Forth, Tiny Pascal, VTL (Very Tiny Language), LISP, some smaller advanced Basics, and even a trimmed down version of Applesoft with all its fixes.

Also a lot of common subroutines can be stored in ROM and save a lot of space in RAM, such as: Memory Move routines, Input routines, Fonts, cursor sprites, etc.

I take it your project does not include a character ROM, so you will need all the character bitmaps and a character generator to print to the screen.

[ashtons]

IamRob wrote:

Many languages will fit into 8k of ROM. To name a few: Forth, Tiny Pascal, VTL (Very Tiny Language), LISP, some smaller advanced Basics, and even a trimmed down version of Applesoft with all its fixes.

Also a lot of common subroutines can be stored in ROM and save a lot of space in RAM, such as: Memory Move routines, Input routines, Fonts, cursor sprites, etc.

I take it your project does not include a character ROM, so you will need all the character bitmaps and a character generator to print to the screen.

I might look into implementing Forth at the very least as an alternative to BASIC and assembly. And common subroutines are stored in ROM - but in the system ROM rather than the program ROM.

As for the character ROM part, the display's controller IC has a built-in CGROM with 128 characters. It appears the module also has RAM on-board as well, and a portion of that can be set aside as CGRAM. So, I'll only really have to worry about the latter 128 characters.

BigEd wrote:

Welcome!

I'd be interested to know what the first 12 programs are.

Here are some ideas, depending a bit on the peripherals you'd have:
- a calculator
- an alarm clock
- a simon type game
- a lunar landing type game
- a cows and bulls type game
- a basic interpreter (perhaps tinybasic)
- a VTL interpreter
- some kind of rolling demo as a crowd-pleaser

I probably should have listed the 12 programs I already figured out, my bad.
- BASIC (might be tinybasic, might be EhBASIC, might be custom, who knows!)
- A combination assembler and machine monitor
- A code and text file editor
- A record file editor
- A bitmap editor
- A font editor (could probably be merged with the bitmap editor)
- A beep sequencer program (make music)
- The corresponding viewer programs
- A file manager
- A terminal program

As for your ideas:
- Calculator: Could be useful.
- Alarm Clock: No RTC, impossible
- The Games: Will look into putting at least one game in the ROMs. Also, cows and bulls??
- Demo: makes sense to add.

Dr Jefyll wrote:

ashtons wrote:

I've already figured out what the first 12 should be, but I can't think of anything for the last 4.

Maybe you should forget about this problem (?) for now, and concentrate instead on getting the machine built and working. Then later (when you've had a chance to play with the first 12 programs) you'll have a better idea of what to do next.

Just a suggestion. Have fun and keep us posted!

-- Jeff

A good point. The main reason I wanted to get this figured out was so I had somewhat of a solid plan. And I will have fun and keep y'all posted!

barrym95838 wrote:

ashtons wrote:

... the display is going to be a NHD-240128WG-ATFH-VZ# (240px by 128px, text or graphics) ...

Sounds like a potential candidate for a Tetris port.

Insert Tetris theme here.

[GARTHWILSON]

Quote:

- Alarm Clock: No RTC, impossible

Au contraire, mon ami! You said you'll have a 65c22. Use its T1 timer to produce an interrupt every 10ms to update the time and date bytes in memory, and if there's an alarm pending, compare to see if you've reached its time yet. I've been doing it for three decades, and I have code at http://wilsonminesco.com/6502interrupts/#2.1 in the 6502 interrupts primer and at http://wilsonminesco.com/multitask/index.html#alm in the article on simple multitasking methods.

[ashtons]

GARTHWILSON wrote:

Quote:

- Alarm Clock: No RTC, impossible

Au contraire, mon ami! You said you'll have a 65c22. Use its T1 timer to produce an interrupt every 10ms to update the time and date bytes in memory, and if there's an alarm pending, compare to see if you've reached its time yet. I've been doing it for three decades, and I have code at http://wilsonminesco.com/6502interrupts/#2.1 in the 6502 interrupts primer and at http://wilsonminesco.com/multitask/index.html#alm in the article on simple multitasking methods.

I honestly didn't think of that. That'll actually be useful. Whenever I think of an RTC, I think of something like a Dallas RTC, not a register on a general IO chip. But, then again, didn't the C64 do something similar with its CIAs?

[GARTHWILSON]

ashtons wrote:

I honestly didn't think of that. That'll actually be useful. Whenever I think of an RTC, I think of something like a Dallas RTC, not a register on a general IO chip. But, then again, didn't the C64 do something similar with its CIAs?

It's not using registers on the '22, except for the configuration and the timer/counter registers. The time and date records, and the alarm information, are kept in RAM variables, and operated on by the interrupt-service routine (ISR).

Dedicated RTC ICs generally don't have such fine resolution. I used one that only had one-second resolution. Many have 100ms resolution. With the VIA, you'll probably have 10ms resolution, or finer if you run at 10MHz or above. One of the things I use it for is timing for key debouncing and repeat speed and the delay before the auto-repeat starts. For that, 100ms (1/10th second) is too coarse. Same thing with things like timing a quick LED flash to indicate low battery, where the length of flash, or the delay between flashes, gives an accurate idea of how much battery life is left. And BTW, since an ISR is updating the RAM time bytes, many tasks taking turns running can access the same bytes to see when it's time to do their next action, and if they haven't reached the target time, pass control to the next task. I've done multitasking like this even on PIC16 microcontrollers, switching tasks over 10,000 times per second, and all timed events run on schedule, without interfering with each other.

Do read the 6502 primer which was written to answer the questions and problems that kept coming up on the forum about making your own 6502 computer, and to a lesser extent, starting to program it. You'll find other things on the site to be valuable too. For example, the multitasking stuff mentioned above is in the article about that, at http://wilsonminesco.com/multitask/ .

[BigDumbDinosaur]

ashtons wrote:

GARTHWILSON wrote:

Quote:

- Alarm Clock: No RTC, impossible

Au contraire, mon ami! You said you'll have a 65c22. Use its T1 timer to produce an interrupt every 10ms to update the time and date bytes in memory, and if there's an alarm pending, compare to see if you've reached its time yet. I've been doing it for three decades, and I have code at http://wilsonminesco.com/6502interrupts/#2.1 in the 6502 interrupts primer and at http://wilsonminesco.com/multitask/index.html#alm in the article on simple multitasking methods.

I honestly didn't think of that. That'll actually be useful.

What Garth described is a "jiffy interrupt." All major operating systems use that basic method of timekeeping. Traditional UNIX uses the 100 Hz (10ms) rate to maintain a seconds-since-long-ago count (the time_t "clock") that can be converted to broken-down (human-readable) time using four-function integer arithmetic. The basic mechanism that maintains time_t can also be used to maintain system uptime and generate alarms (it's a simple comparison process).

Quote:

Whenever I think of an RTC, I think of something like a Dallas RTC, not a register on a general IO chip.

An RTC is a piece of hardware. It would be used to set the time_t clock during bootup. Thereafter, time references would be to time_t, which is in RAM. That has two advantages, one of which is RAM is much faster than an I/O access to an RTC. The other, which Garth mentioned, is granularity. Timekeeping in software can be very fine if your jiffy IRQ occurs often enough.

The mechanism for maintaining time_t, as Garth explained, is the jiffy IRQ generated by the 65C22's timer. That timer is slaved to the Ø2 clock, which is usually generated by a crystal oscillator. Such oscillators can exhibit good long-term drift, which means timekeeping can be quite stable. I use a similar arrangement in my POC units—though not with a 65C22, and one of those machines drifts only a fraction of a second per month. That's better than the alarm clock in my wife's office.

Quote:

But, then again, didn't the C64 do something similar with its CIAs?

In the C-64, timer A of CIA #1 is set up to interrupt at approximately 60 Hz in an NTSC unit, or approximately 50 Hz in a PAL unit. Timekeeping is not particularly accurate. Firstly, it's not possible to program the CIA timers to interrupt exactly at either of those speeds, since Ø2 is not an exact multiple of either rate. Secondly, serial bus activity steals IRQs away from the keyboard scan and TI$ jiffy clock update code, causing a loss of time. Even worse, using the VIC-II raster interrupt, a common technique in games, can further disrupt timekeeping.

Any C-64 application in which an accurate time-of-day was needed used the TOD clock in one of the CIAs. Those are driven from the power line frequency, making for good long-term accuracy.

In the C-128 when running in 128 mode, jiffy IRQs are caused by the VIC raster interrupt, which is synced to the power line frequency. Hence TI$ is a little more reliable...at least until serial bus activity starts up. Again, the CIA TOD clock is a better choice.

[ashtons]

Alright.

(Also, quick question for Garth - what is the n in the T1 period equation on your website?)

[GARTHWILSON]

ashtons wrote:

Alright.

(Also, quick question for Garth - what is the n in the T1 period equation on your website?)

It's the 16-bit number you store in the T1 latch, if I'm interpreting your question correctly.

[BigDumbDinosaur]

GARTHWILSON wrote:

ashtons wrote:

Alright.

(Also, quick question for Garth - what is the n in the T1 period equation on your website?)

It's the 16-bit number you store in the T1 latch, if I'm interpreting your question correctly.

Sounds right.

[ashtons]

In that case, I'm wondering what the hell I'm supposed to do with the 71.728 I got when I solved for n, putting 10ns in for T (the T1 period) and putting in 7.3728 MHz in for p (phi2). Am I supposed to just round down the phi2 to 7 MHz? If so I would get a 68 as a result instead, which makes more sense.