1 NEW STUFF
1.1 ATF1508
2026.09.03 (HW verze retro-003)
- píšu si poznámky, co potřebuju pro úspěšné odladění a otestování ATF3 - zkouším emulovat kompletní systém v práci
- Comp24_ATF_GLUE.PSI zdroják pro Comp24_ATF_GLUE.SI po zpracování pomocí PSI2SI.py preprocesoru
- používám SOviewer.py pro zobrazení Comp24_ATF_GLUE.SO souboru + retro-003-simul.kicad_sch upravené schema z KiCadu aby mělo signály a vzhled celeho systému + background-retro3-simil-clean.png zkombinované printscreeny toho schématu jako podklad pro kreslení v LED režimu
- ATF1508 je rychlé, pokud v jednom taktu ATmega2560 vznese požadavek (nastaví wire hodnotu), tak v následujícím taktu už jsou všechny důsledky "dávno" splněny, netřeba na nic čekat
Význam signálů
- obecně
- X_S_16 je 16.bit adresy, řídí ATF resp. MHF
- X_S_* jsou signály od ATF pro SharedRAM/SystemRAM
- X_SHARED_* jsou signály mezi ATF a MHF
- vždy
- I X_HALT - způsobí HALT CPU a tudíž in_HALT_mode, jeho uvolnění ruší in_HALT_mode (pokud ho nedrží druhá karta). Slouží jako hlavní vyjádření zájmu, dokud ho drží MHFA, může co chce, až ho pustí může co chce MHFB a až ho pustí i ono, tak vládne CPU.
- I X_READ - 1 = MHF bude číst, 0 = MHF bude psát (jestli se mu to povede a kam směřuje požadavek určují další signály)
- I X_SHARE_SELECT - 1 = MHF chce interagovat s SharedRAM, 0= MHF chce interagovat se SystemRAM(/SystemROM - časem)
- I X_SHARE_REQUEST - MHF požadavek na práci s cílem 1 = chip select (a tedy i !Read nebo !Write a případně otevření gates) - splnění požadavku označí X_SHARE_GRANTED, 0 = cíl nemá !CS
- O X_S_READ SharedRAM ~{OE} 0=Active
- O X_S_WRITE SharedRAM ~{WE} 0=Active
- O X_G_ENABLE Gate enabled 0=Enabled 1=HiZ
- O X_G_A_DIR Address dir 1=MHF->CPU 0=CPU->MHF
- O X_G_D_DIR Data dir 1=MHF->CPU 0=CPU->MHF
- pokud je in_HALT_mode
- I X_S_16 je 16.bit adresy, řídí MHF
- I X_SHARE_SELECT - 1 = MHF chce interagovat s SharedRAM, 0= MHF chce interagovat se SystemRAM(/SystemROM - časem)
- I X_SHARE_COOP pokud je X_SHARE_SELECT == 1 tak 1=cíl je SystemRAM, 0=cíl je SystemROM, jinak ignorováno
- O A_SHARE_GRANTED 1=MHF owns everything, 0=MHF owns nothing
- pokud není in_HALT_mode
- I/O X_S_16 je 16.bit adresy, řídí vlastník SharedRAM
- O X_SHARE_COOP pokud je X_SHARE_GRANTED == 1 tak 1=CPU wants SharedRAM, pokud je X_SHARE_GRANTED == 0, tak 1=CPU already got SharedRAM
- O A_SHARE_GRANTED 1=MHF owns SharedRAM
- x A_SHARE_SELECT se ignoruje *)
Jednotlivé fáze bootu:
- Na počátku pullupy nastaví příčetné prostředí
- Reset DOWN s RC členem, který ho postupně vytáhne UP a ukončí Reset fázi
- HALT na CPU card 50 kΩ UP - pro normální start
- X_HALT na MHFX 10 kΩ DOWN - pro řízený start s MHF kartou
- BootSrc switch řídí, zda se bootuje z RAM=0 nebo ROM=1
- Řízený start s MHF kartami (in_HALT_mode)
- A_HALT / B_HALT stáhnou HALT dolů ještě během Reset fáze => CPU nic nedělá a čeká
- HALT => CPU nastaví BA nahoru => jsme v in_HALT_mode
- Pokud jsou přítomné obě karty má přednost A a řídí se to podle A_HALT
- X_SHARE_COOP (dříve X_SHARE_DIRTY) v normálním režimu říká, zda protistrana kooperuje, naopak v in_HALT_mode ji řídí MHFX a nastavuje si, zda chce SystemRAM nebo SystemROM
- X_SHARE_GRANTED v in_HALT_mode znamená, že tato MHF karta je aktivní a může jednat se System Busem
- aktivní karta používá X_SHARE_SELECT k nastavení, která strana gates je jejím cílem - 1=manage SharedRAM, 0=manage SystemRAM + SystemROM
- aktivní karta používá X_READ k nastavení, zda bude číst=1, nebo psát=0
- aktivní karta používá v in_HALT_mode X_SHARE_REQUEST pro nastavení, zda je vybraná RAM aktivovaná (CS čili RAM_Sel)
- => X_SHARE_SELECT + X_SHARE_REQUEST aktivuje danou kartu a X_READ určí směr dat, gates se tomu přizpůsobí
- Zapisování do SystemRAM v in_HALT_mode
- X_HALT = 0 (potvrzení pulldown a vlastní řízení)
- MHF: data INPUT, address INPUT, X_READ =1, X_SHARE_COOP =1 (SystemRAM)/ =0 (SystemROM), X_SHARE_SELECT =1 (CPU side)
- MHF: X_SHARE_REQUEST =1 a čeká na X_SHARE_GRANTED (buď dostane ihned, nebo za dlouho, pokud není A, ale B)
- address = ADDR, address = OUTPUT
- X_READ =0 (zapisujeme, nevíme co, ATF je moc rychlé)
- data = DATA, data = OUTPUT (zapisujeme požadovaná DATA)
- X_READ =1 (čteme zpět, bus konflikt, ale obě strany jsou stejné)
- data=INPUT (konec konfliktu)
- loop pro další addr+data
- doporučeno: nejdřív nastavit hodnotu (čímž se aktivují pullupy), pak nastavit OUTPUT (aby tam nebyly chvíli nějaká pochybná data na výstupu), případně hodnotu zapsat ještě jednou.
- address =INPUT
- X_SHARE_REQUEST =0 (X_SHARE_GRANTED sice ztratíme, ale v in_HALT_mode nám to nevadí, řídíme se podle X_HALT)
- nové X_SHARE_COOP a/nebo X_SHARE_SELECT a znovu X_SHARE_REQUEST =1 a čeká na X_SHARE_GRANTED a pak zase ta smyčka atd. atd.
- mmm
2 OLD STUFF
Jak pokračuju s vývojem, tak se věci mění - 2 ATF1504 zabíraly dost místa na desce, rozvržení vývodů nebylo asi šťastné a rovnice se dobře nevcházely do ATF2, takže jsem zvolil raději jedno ATF1508 a podařilo se mi najít rozumnou dokumentaci a ledacos si "osahat", rozchodit simulaci a napsat si programy, které ji vizualizují a ukazují konflikty.
Stará verze z 2024.06.04 04:39:41 ukazuje původní představy
Click here for expand/collapse
2.1 CPLD
- ATF1504AS: 64 macrocells, 64 I/O for use
- System bus:
- !Reset: global Input pin, sets internal values to zero (but other functions are still enabled)
- !HALT: Output pin, pullup, connected to CPU, either driven LOW or 3stated (HighZ, normal state) - reflects A_HALT state
- [A0..15]: Input bus, used for address decoding and internal registers access
- [D0..7]: I/O bus, used for internal registers access
- Arduino part:
- !A_HALT: Input pin, pulldown, connected to Arduino0, after reset LOW, until Arduino0 set it HIGH
- A{0,1}_ToAct: output, if HIGH, the coresponding Arduino should process its RAM{2,3}, set by CPU releasing the RAM, reset by Arduino releasing the RAM
- A{0,1}_WantRAM: input, if HIGH, the coresponding Arduino wants to own its RAM{2,3}, if LOW, Arduino release the RAM
- A{0,1}_OwnRAM: output, if HIGH, the coresponding Arduino have RAM granted, set by CPU releasing the RAM, reset by Arduino releasing the RAM
- RAM{2,3} part: active only if CPU owns the RAM, otherwise 3stated (HighZ)
- _CE: if CPU owns the RAM. Also sets address 245' OE and dir from CPU
- _OE: if E and Rw are active. Also sets data 245' OE and dir to CPU
- _WE: if E is active and Rw is not. Also sets data 245' OE and dir from CPU
- gate{2,3} part:
- _DATA:
- _ADDRESS:
- _DIR: 0=from CPU, 1=to CPU
- _OE:
2.2 Arduino0
- System bus:
- E: R/O, for timing
- Rw: R/W, for HALT time
2.3 Boot sequence
- Power on / reset:
- Reset line is hold down, then (relatively) slowly rises up
- Arduino{0,1} is reseted, all pins are input (HighZ), setup() is initiated
- CPLD have all registers zeroed, otherwise works
- RAM{2,3} are not owned
- A_HALT is propagated to HALT
- CPU is HALTed, before Reset rises high enought, then the internal reset starts (in halted state)
- starting:
- Arduino0:
- keeps A_HALT down
- keep system Rw high (Read)
- propagates Address Buss to CPU, Data Bus is 3stated(HighZ)
- reads configuration from SD (or default from Flash)
- writes "ROM" content into RAM:
- sets Address lines, set Data lines, set Rw low (write) and opens Data Bus to CPU, waits at least one full E cycle, then sets Rw high(Read) and then sets Data Bus 3stated(HighZ) (as the data are the same for write and then read, no conflict occures), then repeat for next byte
- 3states Address Bus and Rw
- push A_HALT high
- CPU:
- after HALT rises, continue Reset by reading FFFE vector from "ROM"
- initialise all devices
- starts system
2.3.1 Reset, halt, boot
idea - Click to expand/collapse
This is the content that can be expanded or collapsed.
On end of !RESET everything should be reset to its initial state (no RAM23 mapped/owned etc.)
While !HALT is CPU supressed and Arduino1 (master of RAM2) owns CPU busses and (temporaly) RAM2. (CPLD should keep open gate for address and commands from Arduino1 to CPU and data gate dependind on CPU's Rw)
Usually computer should start (boot) to !RESET and !HALT will be issued ASAP, then Arduino1 will prefill "ROM" area of RAM01 (usually C090-FFFF, and especially vectors on FFF0-FFFF) and release the HALT after RESET is released.
Also on reboot there should be !RESET with !HALT.
On the other hand I do not forsee !HALT without !RESET to have much use other then DMA or debug (wow, sounds interesting now).
again and better:
2.3.2 Boot/Reboot/Reset Logic with HD6309, CPLD, and Arduino
I have HD6309, CPLD, and Arduino. I need to decide on boot/reboot/reset logic.
2.3.2.1 Power-Up Behavior
Power-up the same as reboot/reset. There will be no different logic for hot reset at this level.
- Delay: There will be a delay circuit, like a capacitor to ground and a 10k resistor to PWR for the reset pin to have a slow start.
- Button: There will be a hardware button (or more) from the reset pin to GND. Once pressed, it starts rebooting, but the reset pin will be delayed by the capacitor as on power-up.
- CPU Reset: The reset pin has a threshold point higher than usual, so everything else may react to the end of the reset sooner than the CPU (which is good).
2.3.2.1.1 Arduino Reset and HALT Control
- The Arduino will reset too, starting to work at the same time or sooner than the CPU. However, the Arduino setup is long, so it would act too late.
- Therefore, there must be something to pull HALT down when RESET is down and let it go (to pull up) after the Arduino is fully awake. This means that the Arduino must send a signal to release the HALT.
- Ideally, the Arduino could also manipulate HALT freely or leave it intact.
- Resume: On Arduino side the A_HALT line will be pulled down and Arduino will push it HIGH, on CPU side the HALT line will be pulled up and tristated when A_HALT is high (otherwise forced LOW).
2.3.2.2 Additional Logic and Connections
- There must be a gate for Rw from Arduino to CPU (but it is not what I need).
- On the CPU side, HALT should have a pull-up.
- On the Arduino side, A_HALT should be an input with a pulldown. When A_HALT is LOW, HALT must be low too. When A_HALT is HIGH, HALT must be released (and go up to pull-up).
- In the future, HALT may be used by something else, so the release is going to 3-state and let the pull-up do its work.
- When A_HALT is not high, then Arduino owns the CPU buses, so gates must be open in the right direction.
- Arduino may also acquire ROM2 while A_HALT is low to be able to fill it later.
+----- 3k3 --------------------+-- Halt HD6309
| |
| +----------------- Halt CPLD
|
|
|
+5V -+---- 10k --+-----+-----+------+-- Reset HD6309
| | | |
| | | +----------------- Reset CPLD
| | | |
1µF 1M RESET +-------------------------------------- Reset Arduino1
| | BUTTON |
| | | +-------------------------------------- Reset Arduino2
| | |
GND -------------+-----+-----+
+5V -----------+
|
100k
|
CPLD A_Halt ---+----------+------ A_Halt Arduino1
|
3k3
|
GND ----------------------+------ GND Arduino
chatGPT halucinations (WRONG, totally WRONG) - Click to expand/collapse
This is the content that can be expanded or collapsed.
Designing a robust reset and boot logic circuit with the HD6309 CPU, a CPLD, and an Arduino requires careful consideration of the interaction between these components. Here’s a detailed plan to achieve the desired functionality: Components Involved:
- HD6309 CPU
- CPLD (Complex Programmable Logic Device)
- Arduino
- Reset Circuit (capacitor and resistor)
- Manual Reset Button
Requirements:
- Power-Up Sequence: Ensure the CPU, Arduino, and other components start correctly and in sequence.
- Manual Reset: Allow manual reset via a button with a capacitor delay.
- Arduino HALT Control: Arduino should control the HALT line of the CPU after it finishes its setup.
- Bus Control: When HALT is asserted, Arduino should control the CPU buses.
Proposed Design: Power-Up and Reset Circuit:
Reset Pin (RESET): Connect a capacitor (e.g., 10µF) to ground and a 10kΩ resistor to the power supply (Vcc) to create a delay circuit. Manual Reset Button: Connect a normally open push button between the RESET pin and ground.
CPLD Logic:
HALT Control: Use the CPLD to handle the HALT line control logic. Bus Control: Use the CPLD to manage the CPU bus direction based on the state of the HALT line and A_HALT signal from the Arduino.
Arduino Control:
A_HALT Pin: An input pin on the Arduino with an internal pulldown resistor. When A_HALT is HIGH, the HALT line should be released (3-state); when LOW, the HALT line should be asserted. Signal to Release HALT: Arduino should send a signal to release the HALT line after completing its setup.
Circuit Diagram:
+5V ----+----- 10kΩ ------+-------+-------- RESET (HD6309)
| | |
| | |
| | |
10µF RESET |
| BUTTON |
| | |
GND GND |
|
A_HALT (Arduino) ------+----------|--------> HALT (HD6309)
| |
| |
CPLD CPLD
Logic Logic
for HALT for Bus Control
CPLD Logic Design:
- HALT Control Logic:
- If A_HALT from Arduino is LOW, assert HALT (pull to ground). If A_HALT is HIGH, release HALT (3-state, let the pull-up resistor pull it high).
- Bus Control Logic:
- If HALT is asserted, Arduino takes control of CPU buses. Ensure appropriate bus direction settings based on the state of HALT.
Steps to Implement:
- Power-Up Initialization:
- On power-up, the capacitor and resistor create a delay on the RESET pin, ensuring a proper reset sequence. The CPLD holds HALT low until the Arduino sets A_HALT high.
- Manual Reset:
- Pressing the reset button grounds the RESET pin, initiating a reset sequence. The capacitor ensures a delayed release of the reset pin, similar to the power-up sequence.
- Arduino Initialization:
- On reset, the Arduino starts its setup process. After setup, Arduino sets A_HALT high to release the HALT line via CPLD logic.
- Bus Control:
- When HALT is low, the CPLD ensures the Arduino controls the CPU buses. When HALT is released, normal CPU operation resumes, and the buses are controlled by the CPU.
Additional Considerations:
CPLD Programming: Ensure the CPLD is programmed to manage the HALT and bus control logic correctly. Timing: Verify timing requirements for the reset and setup sequences to avoid conflicts. Future Expansion: Design the HALT control logic in the CPLD to accommodate future requirements, such as additional components asserting HALT.
By implementing this design, the HD6309, Arduino, and CPLD will interact correctly during power-up, reset, and normal operation, with the Arduino being able to control the HALT line and CPU buses as needed.
End of HALUCINATIONS
2.3.3 RAM0 + RAM1
RAM0 is easy, mapped on 0000-7FFF with nothing interfering
RAM1 is mapped on 8000-FFFF, but overlayed by devices (C000-C07F), registers (C080-C081) and sometimes by RAM2 or RAM3 (8000-BFFF)
Both use qualified Rw for OE and qualified !Rw for WE
PIN = [A0..A15]; /* I; active high CPU address bus */
PIN = [D0..A7]; /* I; active high CPU data bus */
PIN = E; /* I; active high E CPU.34 System clock */
PIN = Rw; /* I; active high R/~{W} CPU.32 1=Read; 0=Write */
PIN = !RAM0_CS; /* O; active low Chip select for RAM0 */
PIN = !RAM1_CS; /* O; active low Chip select for RAM1 */
PIN = !RAM01_OE; /* O; active low Read qualified by E For RAM0, RAM1 */
PIN = !RAM01_WE; /* O; active low Write qualified by E For RAM0, RAM1 */
RAM01_OE = E & Rw;
RAM01_WE = E & !Rw;
PIN = !RAM2_CS; /* O3; active low Chip select for RAM2 */
PIN = !RAM3_CS; /* O3; active low Chip select for RAM3 */
2.4 Junk to be deleted later
Name Comp24_CPLD; PartNo ATF1504; Date 2024-06-04; Revision 1; Designer ChatGPT; Company OpenAI; Assembly None; Location None; Device g22v10; PIN 1 = CPU_A15; PIN 2 = CPU_A14; PIN 3 = CPU_A13; PIN 4 = CPU_A12; PIN 5 = CPU_A11; PIN 6 = CPU_A10; PIN 7 = CPU_A9; PIN 8 = CPU_A8; PIN 9 = CPU_A7; PIN 10 = CPU_A6; PIN 11 = CPU_A5; PIN 12 = CPU_A4; PIN 13 = CPU_A3; PIN 14 = CPU_A2; PIN 15 = CPU_A1; PIN 16 = CPU_A0; PIN 17 = CPU_R_W; PIN 18 = CPU_E; PIN 19 = CPU_CS; PIN 20 = RAM_CE; PIN 21 = RAM_OE; PIN 22 = RAM_WE; PIN 23 = ADDR14; PIN 24 = PAGE_REG; PIN 25 = STATUS_REG; PIN 26 = RAM2_CE; PIN 27 = RAM3_CE; PIN 28 = RAMowned; PIN 29 = RAMwanted; PIN 30 = shouldAct; PIN 31 = VCC; PIN 32 = GND; // Signals for Arduino integration PIN 33 = Ard1want; PIN 34 = Ard2want; PIN 35 = toAct1; PIN 36 = toAct2; Field PAGE_REG_FIELD = [PAGE_REG]; // Page Register Values #define PAGE_RAM1 0b000 #define PAGE_RAM2_L 0b100 #define PAGE_RAM2_H 0b101 #define PAGE_RAM3_L 0b110 #define PAGE_RAM3_H 0b111 // Address Range Definitions #define ADDR_RANGE_RAM0_START 0x0000 #define ADDR_RANGE_RAM0_END 0x7FFF #define ADDR_RANGE_RAM1_START 0x8000 #define ADDR_RANGE_RAM1_END 0xFFFF #define ADDR_RANGE_IO_START 0xC000 #define ADDR_RANGE_IO_END 0xC07F #define ADDR_RANGE_CPLD_START 0xC080 #define ADDR_RANGE_CPLD_END 0xC081 // Control Logic RAM_CE = !CPU_CS & (CPU_A15 & CPU_A14 & CPU_A13 & CPU_A12); // Control enable logic RAM_OE = !CPU_R_W & CPU_E; // Output enable logic RAM_WE = CPU_R_W & CPU_E; // Write enable logic // Address Line 14 (addr14) Control ADDR14 = PAGE_REG_FIELD[0]; // RAM Chip Select based on Page Register RAM2_CE = (PAGE_REG_FIELD == PAGE_RAM2_L) | (PAGE_REG_FIELD == PAGE_RAM2_H); RAM3_CE = (PAGE_REG_FIELD == PAGE_RAM3_L) | (PAGE_REG_FIELD == PAGE_RAM3_H); // Status Register Bits owned = RAMowned; Ard1want = RAMwanted & (PAGE_REG_FIELD == PAGE_RAM2_L | PAGE_REG_FIELD == PAGE_RAM2_H); Ard2want = RAMwanted & (PAGE_REG_FIELD == PAGE_RAM3_L | PAGE_REG_FIELD == PAGE_RAM3_H); toAct1 = shouldAct & (PAGE_REG_FIELD == PAGE_RAM2_L | PAGE_REG_FIELD == PAGE_RAM2_H); toAct2 = shouldAct & (PAGE_REG_FIELD == PAGE_RAM3_L | PAGE_REG_FIELD == PAGE_RAM3_H); // Page Register Logic FIELD PAGE_REG = [CPU_A0, CPU_A1, CPU_A2]; PAGE_REG = CPU_R_W & CPU_CS & (CPU_A15 & CPU_A14 & CPU_A13 & CPU_A12); // Status Register Logic STATUS_REG = CPU_R_W & CPU_CS & (CPU_A15 & CPU_A14 & CPU_A13 & CPU_A12); STATUS_REG[0] = owned; STATUS_REG[1] = Ard1want; STATUS_REG[2] = Ard2want; STATUS_REG[3] = toAct1; STATUS_REG[4] = toAct2; END;
CPLD