| 1 |
## Overview
|
| 2 |
Gromulus is an application for organizing and deduplicating games collections, with a focus on older ROM based games for systems like Nintendo, Super Nintendo,
|
| 3 |
Sega Genesis, Nintendo Game Cube, and 3DO. This also includes non-console systems, like the Atari ST, Commodor 64, commodor Amiga, and the Apple II.
|
| 4 |
|
| 5 |
Across many of my computers, over the years, I ended up with many copies of the same game rom image. They are named slightly differently but the image
|
| 6 |
is the exact same file. Also, many of these are misslabled. Some are european versions, while some others are named incorrectly.
|
| 7 |
|
| 8 |
This program will:
|
| 9 |
- Organize these ROM images into a database and on the file system.
|
| 10 |
- Deduplicate them by not allowing the import of ROM files where by the MD5 Hash that game ROM already exists
|
| 11 |
- Using the DAT files from TOSEC and NoIntro, will properly label the ROM images that are misslabled.
|
| 12 |
- Games ROMs that dont have matching MD5 Hash values in the DAT files will still be indexed and added. The main focus of the program is still
|
| 13 |
deduplication.
|
| 14 |
- Will also ingest, organize, and display game artwork.
|
| 15 |
- Will display these in on a list GUI, for browsing the collection.
|
| 16 |
- Uses wxPython for the GUI
|
| 17 |
- main_app_file_hash is central to matching logic.
|
| 18 |
- The program remembers the last time a DAT file was ingested, with version tracking, so that the user knows if it should be updated.
|
| 19 |
- The program handles file naming issues where two rom files have the same name but different hash values. The program adds an incrementing number to the end, so that you have both files in the directory.
|
| 20 |
|
| 21 |
This file represents my spec-driven development workflow and will be continuously refactored as a living contract for change boundaries and acceptance criteria.
|
| 22 |
|
| 23 |
|
| 24 |
### Future Enhancements
|
| 25 |
- Will also support scraping game information from available game databases on the internet.
|
| 26 |
- Will support user editable fields, for games that dont have scraped information.
|
| 27 |
- Will suport copying games to an SD card, so that these games can be used on a MISTer.
|
| 28 |
- Will also support reading the games on these SD cards to show which games have been copied to the card and which have not, so the user can
|
| 29 |
add additional games to the card.
|
| 30 |
|
| 31 |
---
|
| 32 |
|
| 33 |
## Spec Template (Working Draft)
|
| 34 |
This section is a lightweight template for spec-driven development. Keep this as a living section and refine it as implementation evolves.
|
| 35 |
|
| 36 |
### 1. Feature / Change Name
|
| 37 |
- Name:
|
| 38 |
- Status: `draft | approved | in_progress | done`
|
| 39 |
- Owner:
|
| 40 |
- Last updated:
|
| 41 |
|
| 42 |
### 2. Problem Statement
|
| 43 |
- What user or workflow problem are we solving?
|
| 44 |
- Why now?
|
| 45 |
|
| 46 |
### 3. Scope
|
| 47 |
- In scope:
|
| 48 |
- Out of scope:
|
| 49 |
|
| 50 |
### 4. Requirements (Testable)
|
| 51 |
Use short, testable statements.
|
| 52 |
|
| 53 |
- `R1`:
|
| 54 |
- `R2`:
|
| 55 |
- `R3`:
|
| 56 |
|
| 57 |
Optional (Given/When/Then style):
|
| 58 |
- Given:
|
| 59 |
- When:
|
| 60 |
- Then:
|
| 61 |
|
| 62 |
### 5. Data / Schema Impact
|
| 63 |
- Tables touched:
|
| 64 |
- Columns touched:
|
| 65 |
- New indexes/constraints:
|
| 66 |
- Migration/backfill required:
|
| 67 |
|
| 68 |
### 6. UX / Workflow Impact
|
| 69 |
- Screens/menus affected:
|
| 70 |
- User-visible behavior changes:
|
| 71 |
- Failure/error messages:
|
| 72 |
|
| 73 |
### 7. Non-Functional Requirements
|
| 74 |
- Performance:
|
| 75 |
- Reliability:
|
| 76 |
- Safety/data integrity:
|
| 77 |
- Logging/observability:
|
| 78 |
|
| 79 |
### 8. Acceptance Criteria
|
| 80 |
- [ ] Criterion 1
|
| 81 |
- [ ] Criterion 2
|
| 82 |
- [ ] Criterion 3
|
| 83 |
|
| 84 |
### 9. Test Plan
|
| 85 |
- Unit tests:
|
| 86 |
- Integration/manual tests:
|
| 87 |
- Edge cases:
|
| 88 |
|
| 89 |
### 10. Rollout / Recovery
|
| 90 |
- Rollout steps:
|
| 91 |
- Backout plan:
|
| 92 |
- Manual recovery steps:
|
| 93 |
|
| 94 |
### 11. Open Questions
|
| 95 |
- Q1:
|
| 96 |
- Q2:
|
| 97 |
|
| 98 |
### 12. Decision Log
|
| 99 |
- Date / Decision / Rationale / Alternatives considered
|
