Difference between revisions of "F256K"
HaydenKale (talk | contribs) (→Memory) |
|||
(12 intermediate revisions by one other user not shown) | |||
Line 6: | Line 6: | ||
* Port for connecting FNX4N4S, which can be used to connect Atari-Style Joysticks or NES/SNES gamepads | * Port for connecting FNX4N4S, which can be used to connect Atari-Style Joysticks or NES/SNES gamepads | ||
* 1x IEC Port to interface to Commodore Drives | * 1x IEC Port to interface to Commodore Drives | ||
− | * SID | + | * A few sound chips: SID, PSG/SN76489, OPL3 |
+ | * 1x Simple 3-wire UART (RS-232 Port, [[F256_WiFi|Feather ESP8266 wifi]] | ||
It shares many similarities to the [[F256JR]] and programs can in many cases run straightforwardly on both. | It shares many similarities to the [[F256JR]] and programs can in many cases run straightforwardly on both. | ||
Line 24: | Line 25: | ||
* '''Power Switch''' is a toggle-style switch to turn the unit off and on. | * '''Power Switch''' is a toggle-style switch to turn the unit off and on. | ||
* '''Reset Button''' reboots the system, with values in RAM persisting. If RAM has been modified using the debug interface, it stays modified. | * '''Reset Button''' reboots the system, with values in RAM persisting. If RAM has been modified using the debug interface, it stays modified. | ||
− | * '''Power Jack''' is for plugging in A/C power. Use, for example, a +12V or +9V with 2.5mm | + | * '''Power Jack''' is for plugging in A/C power. Use, for example, a +12V or +9V with 2.5mm barrel connector. |
* '''USB Debug''' is for connection to a debug host computer, debugging F256K as a target, for example using a mini USB to USB A cable. | * '''USB Debug''' is for connection to a debug host computer, debugging F256K as a target, for example using a mini USB to USB A cable. | ||
* '''PS/2''' can be used for connecting external keyboard and/or mouse. | * '''PS/2''' can be used for connecting external keyboard and/or mouse. | ||
Line 69: | Line 70: | ||
Switching DIP1 to 'on' is useful for developer convenience and testing code. For those using the machine outside of a development-style environment, it's more likely the switch will be 'off'. | Switching DIP1 to 'on' is useful for developer convenience and testing code. For those using the machine outside of a development-style environment, it's more likely the switch will be 'off'. | ||
− | + | The ''Boot from RAM'' and ''Boot from flash'' options in uploader tools such as [https://github.com/pweingar/FoenixMgr FoenixMgr] or [https://github.com/clandrew/F256Uploader F256 Uploader] are unrelated to the "Boot from RAM" DIP switch: | |
+ | * The DIP switch alters boot behavior by telling the kernel to search the first 48K of RAM for a pre-loaded kernel binary. | ||
+ | * Those tools, on the other hand, initiate a new boot using a soft reset signal, and the choice of ''Boot from RAM'' versus ''Boot from flash'' affects the initial memory look-up tables upon boot. | ||
+ | |||
+ | So those tools' options are also useful for developer convenience, they just affect a different part of the boot process, and are tightly integrated with the act of pushing data over the debug port onto F256K memory. | ||
= Memory = | = Memory = | ||
The F256K has a 16-bit address space, $0000 through $FFFF, visible to its CPU. In other words, the CPU address space is 64KB in size. While other units such as the TinyVicky graphics unit can access memory beyond that, the CPU itself has a 16-bit address space. | The F256K has a 16-bit address space, $0000 through $FFFF, visible to its CPU. In other words, the CPU address space is 64KB in size. While other units such as the TinyVicky graphics unit can access memory beyond that, the CPU itself has a 16-bit address space. | ||
− | + | The address space is divided up into eight equal-sized ''banks''. The CPU-visible address space is divided into banks as follows: | |
− | |||
− | |||
− | |||
− | The address space is divided up into eight equal-sized ''banks''. | ||
− | |||
{| class="wikitable" | {| class="wikitable" | ||
Line 110: | Line 110: | ||
| $E000-$FFFF | | $E000-$FFFF | ||
|} | |} | ||
+ | |||
+ | Note that each bank is $2000 in size; on other (e.g., non-Foenix) platforms, the term ''bank'' may be used differently. Here, each bank is 8KB, or $2000. | ||
+ | |||
+ | Since the F256K has a larger amount of total memory (up to 768KB) than this address space exposes, programs use and adjust the address space as a "window" to underlying memory needed by the CPU at any given time. | ||
+ | |||
+ | In other words, programs control what device memory this address space maps to. They do this through ''memory lookup tables'', or ''MLUT''s for short. Up to four MLUTs can be set up at a time, and programs choose which one is active at any given time. | ||
+ | |||
+ | To ensure that control of MLUTs is always possible, CPU address $0000 is special, and is a memory-mapped register to manipulate MLUTs: | ||
+ | <nowiki> | ||
+ | MMU_MEM_CTRL = $0000</nowiki> | ||
+ | |||
+ | For example, to enable editing of MLUT 0, set the MMU_EDIT_EN (the leftmost) bit: | ||
+ | <nowiki> | ||
+ | LDA MMU_MEM_CTRL | ||
+ | ORA #MMU_EDIT_EN | ||
+ | STA MMU_MEM_CTRL</nowiki> | ||
+ | |||
+ | As for where a bank of CPU address space can map to: programs can map a bank to any of RAM, flash or expansion memory. | ||
+ | |||
+ | An example of a straightforward mapping is to simply map the CPU address space linearly to the first 64KB of RAM. | ||
+ | <nowiki> | ||
+ | LDA #$00 | ||
+ | STA MMU_MEM_BANK_0 ; map $000000 to bank 0 | ||
+ | INA | ||
+ | STA MMU_MEM_BANK_1 ; map $002000 to bank 1 | ||
+ | INA | ||
+ | STA MMU_MEM_BANK_2 ; map $004000 to bank 2 | ||
+ | INA | ||
+ | STA MMU_MEM_BANK_3 ; map $006000 to bank 3 | ||
+ | INA | ||
+ | STA MMU_MEM_BANK_4 ; map $008000 to bank 4 | ||
+ | INA | ||
+ | STA MMU_MEM_BANK_5 ; map $00a000 to bank 5 | ||
+ | INA | ||
+ | STA MMU_MEM_BANK_6 ; map $00c000 to bank 6 | ||
+ | INA | ||
+ | STA MMU_MEM_BANK_7 ; map $00e000 to bank 7</nowiki> | ||
+ | |||
+ | where MMU_MEM_BANK_0, 1, 2, are specially mapped at addresses $0008, $0009, and so on. In this example code, the accumulator stores the bank number of device memory, and that value is written to the corresponding register. Write higher values to map later regions of device memory. | ||
+ | |||
+ | Finally, use | ||
+ | <nowiki> | ||
+ | LDA MMU_MEM_CTRL | ||
+ | AND #~(MMU_EDIT_EN) | ||
+ | STA MMU_MEM_CTRL ; disable mmu edit, use mmu lut 0</nowiki> | ||
+ | to commit the changes and enable use of the updated MLUT 0. | ||
+ | |||
+ | = Sound = | ||
+ | The F256K has a few different components capable of processing sound: | ||
+ | * Two PSG(SN76489) chips | ||
+ | * Two SID chips; SID, or Sound Interface Device, was used on C64 and others | ||
+ | * Yamaha OPL3 chip | ||
+ | |||
+ | The PSG chips are memory-mapped as follows: | ||
+ | <nowiki> | ||
+ | PSG_INT_L_PORT = $D600 ; Control register for the SN76489 | ||
+ | PSG_INT_B_PORT = $D608 ; Control register for the SN76489, writes to both L and R ports | ||
+ | PSG_INT_R_PORT = $D610 ; Control register for the SN76489</nowiki> | ||
= Keyboard = | = Keyboard = | ||
Line 115: | Line 173: | ||
There are two ways for programs to interact with the keyboard: | There are two ways for programs to interact with the keyboard: | ||
− | * '''Using the kernel''', where the exact mechanism depends on the kernel involved | + | * '''Using the kernel''', where the exact mechanism depends on the kernel involved; this can be through an environment like SuperBASIC that talks to the kernel |
* '''Directly with the device''', using memory mappings. | * '''Directly with the device''', using memory mappings. | ||
Latest revision as of 18:43, 4 July 2023
The F256K is a 65xx-based system. It's an encased form factor with a built-in keyboard. It includes the following features:
- 512K of Shared System & Video RAM
- 256k of flash
- 256k of cartridge ram/rom
- TinyVICKY Graphic Chip (CFP9599)
- Port for connecting FNX4N4S, which can be used to connect Atari-Style Joysticks or NES/SNES gamepads
- 1x IEC Port to interface to Commodore Drives
- A few sound chips: SID, PSG/SN76489, OPL3
- 1x Simple 3-wire UART (RS-232 Port, Feather ESP8266 wifi
It shares many similarities to the F256JR and programs can in many cases run straightforwardly on both.
The 'K' in the name comes from the fact that it has an integrated keyboard, unrelated to the amount of memory available in the system. The base system has 512K of system memory; with expansion cartridge brings it up to 768K.
A common variety of the F256K uses the 6502 CPU. That said, the 65816 CPU can also be installed.
Contents
Ports and connectors
The back of the unit looks like this:
- Power Switch is a toggle-style switch to turn the unit off and on.
- Reset Button reboots the system, with values in RAM persisting. If RAM has been modified using the debug interface, it stays modified.
- Power Jack is for plugging in A/C power. Use, for example, a +12V or +9V with 2.5mm barrel connector.
- USB Debug is for connection to a debug host computer, debugging F256K as a target, for example using a mini USB to USB A cable.
- PS/2 can be used for connecting external keyboard and/or mouse.
- FNX4N4S Adapter provides connections to gamepads (e.g., SNES-style game controller) through the FNX4N4S adapter.
- IEC provides connectivity to Commodore-compatible devices that use serial interface
- DVI is for connecting a display.
- RS-232 provides a standard RS-232 serial interface.
- Headphones is a standard 3.5mm headphone jack.
- Audio Line Out provides stereo audio output.
Switches
The bottom of the unit looks like this:
There are eight DIP switches, with different interpretations depending on whether a kernel is present on the system. If a kernel is present on the system, as the unit is shipped with, these switches are:
- [8] - On: Enable GAMMA correction
- [7] - Graphics resolution controls
- [6] - Not used
- [5] - Not used
- [4] - On: Feather Board installed (ESP8266)
- [3] - On: Enable SLIP Base Networking
- [2] - Reserved
- [1] - On: Enable Boot from RAM, off means it will boot from a pre-installed kernel in the first 48K of memory.
If a kernel is not present on the system, these switches can be used as desired:
- [8] - On: Enable GAMMA correction
- [7] - USER2
- [6] - USER1
- [5] - USER0
- [4] - BOOT Mode3
- [3] - BOOT Mode2
- [2] - BOOT Mode1
- [1] - BOOT Mode0
Boot
To start the machine, ensure A/C power is plugged in and flip the power switch. The exact boot behavior depends on the "Boot from RAM" DIP switch on the bottom.
- If the DIP1 "Boot from RAM" switch is off and a kernel is used, the kernel will search the 48K of memory for a pre-loaded kernel binary.
- If the DIP1 "Boot from RAM" switch is on, then control is transferred to the reset vector entrypoint located at offset $FFFC.
Switching DIP1 to 'on' is useful for developer convenience and testing code. For those using the machine outside of a development-style environment, it's more likely the switch will be 'off'.
The Boot from RAM and Boot from flash options in uploader tools such as FoenixMgr or F256 Uploader are unrelated to the "Boot from RAM" DIP switch:
- The DIP switch alters boot behavior by telling the kernel to search the first 48K of RAM for a pre-loaded kernel binary.
- Those tools, on the other hand, initiate a new boot using a soft reset signal, and the choice of Boot from RAM versus Boot from flash affects the initial memory look-up tables upon boot.
So those tools' options are also useful for developer convenience, they just affect a different part of the boot process, and are tightly integrated with the act of pushing data over the debug port onto F256K memory.
Memory
The F256K has a 16-bit address space, $0000 through $FFFF, visible to its CPU. In other words, the CPU address space is 64KB in size. While other units such as the TinyVicky graphics unit can access memory beyond that, the CPU itself has a 16-bit address space.
The address space is divided up into eight equal-sized banks. The CPU-visible address space is divided into banks as follows:
Bank | Address Range |
---|---|
0 | $0000-$1FFF |
1 | $2000-$3FFF |
2 | $4000-$5FFF |
3 | $6000-$7FFF |
4 | $8000-$9FFF |
5 | $A000-$BFFF |
6 | $C000-$DFFF |
7 | $E000-$FFFF |
Note that each bank is $2000 in size; on other (e.g., non-Foenix) platforms, the term bank may be used differently. Here, each bank is 8KB, or $2000.
Since the F256K has a larger amount of total memory (up to 768KB) than this address space exposes, programs use and adjust the address space as a "window" to underlying memory needed by the CPU at any given time.
In other words, programs control what device memory this address space maps to. They do this through memory lookup tables, or MLUTs for short. Up to four MLUTs can be set up at a time, and programs choose which one is active at any given time.
To ensure that control of MLUTs is always possible, CPU address $0000 is special, and is a memory-mapped register to manipulate MLUTs:
MMU_MEM_CTRL = $0000
For example, to enable editing of MLUT 0, set the MMU_EDIT_EN (the leftmost) bit:
LDA MMU_MEM_CTRL ORA #MMU_EDIT_EN STA MMU_MEM_CTRL
As for where a bank of CPU address space can map to: programs can map a bank to any of RAM, flash or expansion memory.
An example of a straightforward mapping is to simply map the CPU address space linearly to the first 64KB of RAM.
LDA #$00 STA MMU_MEM_BANK_0 ; map $000000 to bank 0 INA STA MMU_MEM_BANK_1 ; map $002000 to bank 1 INA STA MMU_MEM_BANK_2 ; map $004000 to bank 2 INA STA MMU_MEM_BANK_3 ; map $006000 to bank 3 INA STA MMU_MEM_BANK_4 ; map $008000 to bank 4 INA STA MMU_MEM_BANK_5 ; map $00a000 to bank 5 INA STA MMU_MEM_BANK_6 ; map $00c000 to bank 6 INA STA MMU_MEM_BANK_7 ; map $00e000 to bank 7
where MMU_MEM_BANK_0, 1, 2, are specially mapped at addresses $0008, $0009, and so on. In this example code, the accumulator stores the bank number of device memory, and that value is written to the corresponding register. Write higher values to map later regions of device memory.
Finally, use
LDA MMU_MEM_CTRL AND #~(MMU_EDIT_EN) STA MMU_MEM_CTRL ; disable mmu edit, use mmu lut 0
to commit the changes and enable use of the updated MLUT 0.
Sound
The F256K has a few different components capable of processing sound:
- Two PSG(SN76489) chips
- Two SID chips; SID, or Sound Interface Device, was used on C64 and others
- Yamaha OPL3 chip
The PSG chips are memory-mapped as follows:
PSG_INT_L_PORT = $D600 ; Control register for the SN76489 PSG_INT_B_PORT = $D608 ; Control register for the SN76489, writes to both L and R ports PSG_INT_R_PORT = $D610 ; Control register for the SN76489
Keyboard
The built-in keyboard does not operate by PS/2 controller, it's a matrix keyboard controlled by two WDC VIA (Versatile Interface Adapter) controllers and the CPU's NMI signal.
There are two ways for programs to interact with the keyboard:
- Using the kernel, where the exact mechanism depends on the kernel involved; this can be through an environment like SuperBASIC that talks to the kernel
- Directly with the device, using memory mappings.
For more information on interacting directly with the keyboard device, see F256K Keyboard.
The F256K also supports plugging in an external keyboard. If this is done, it is through PS/2 interface.
Manual
For a technical reference, use this manual: https://github.com/pweingar/F256Manual
Although the manual is F256Jr-centric, it's suitable for F256K development owing to the similarity of the two units. It describes common aspects between F256Jr and F256K, with some sections highlighting F256K functionality that differs.
Kernels
There are three kernels for the F256K.
- The TinyCore MicroKernel (ships with the unit)
- OpenKERNAL (for those wishing to run software written for the CBM KERNAL)
- FoenixKERNAL, an open source, CBM-style layer also compatible with software written for Commodore 64 KERNAL