Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
struct Memory {
|
|
|
|
string type;
|
|
|
|
string size;
|
2018-04-08 23:50:42 +00:00
|
|
|
string content;
|
Update to v106r09 release.
byuu says:
Changelog:
- higan, icarus, genius: new manifest syntax (work in progress)
Pretty much only LoROM and HiROM SNES games will load right now, and RAM
will only work right if the save.ram file already exists to pull its
file size from (a temporary cheap hack was used.)
Basically, I'm just getting this out there for evaluation.
One minor errata is that I switched icarus to using “memory/battery” to
indicate battery-backed RAM, whereas genius still uses “memory/volatile”
to indicate non-battery-backed RAM.
I intend to make it “memory/battery” in genius, and have the field
auto-enable when RAM or RTC is selected for type (obviously allowing it
to be unchecked for volatile memory.)
I need to update all 64 production boards, and 25 of 29 generic boards,
to use the new slot syntax; and I also need to update every single core
in higan to use the new manifest game syntax. I want to build out a
generic manifest game parser that all emulation cores will use.
Once I finish this, I'll also need to write a database converter to
update all of my licensed game dumps to the new database syntax.
I also need to write up something for doc.byuu.org explaining the new
manifest game syntax. The manifest board syntax will still be “internal”
and subject to revisions, but once v107 is out, the gamepak manifest
format will be set in stone sans extensions.
2018-03-05 04:34:07 +00:00
|
|
|
string manufacturer;
|
2018-04-08 23:50:42 +00:00
|
|
|
string architecture;
|
|
|
|
string identifier;
|
2018-04-15 05:49:53 +00:00
|
|
|
boolean Volatile;
|
Update to v106r09 release.
byuu says:
Changelog:
- higan, icarus, genius: new manifest syntax (work in progress)
Pretty much only LoROM and HiROM SNES games will load right now, and RAM
will only work right if the save.ram file already exists to pull its
file size from (a temporary cheap hack was used.)
Basically, I'm just getting this out there for evaluation.
One minor errata is that I switched icarus to using “memory/battery” to
indicate battery-backed RAM, whereas genius still uses “memory/volatile”
to indicate non-battery-backed RAM.
I intend to make it “memory/battery” in genius, and have the field
auto-enable when RAM or RTC is selected for type (obviously allowing it
to be unchecked for volatile memory.)
I need to update all 64 production boards, and 25 of 29 generic boards,
to use the new slot syntax; and I also need to update every single core
in higan to use the new manifest game syntax. I want to build out a
generic manifest game parser that all emulation cores will use.
Once I finish this, I'll also need to write a database converter to
update all of my licensed game dumps to the new database syntax.
I also need to write up something for doc.byuu.org explaining the new
manifest game syntax. The manifest board syntax will still be “internal”
and subject to revisions, but once v107 is out, the gamepak manifest
format will be set in stone sans extensions.
2018-03-05 04:34:07 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct Oscillator {
|
|
|
|
string frequency;
|
|
|
|
};
|
|
|
|
|
|
|
|
//variant meta-class
|
|
|
|
struct Component {
|
|
|
|
enum class Type : uint {
|
|
|
|
Memory,
|
|
|
|
Oscillator,
|
|
|
|
} type;
|
|
|
|
Memory memory;
|
|
|
|
Oscillator oscillator;
|
Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct Game {
|
|
|
|
string sha256;
|
|
|
|
string region;
|
|
|
|
string revision;
|
|
|
|
string board;
|
|
|
|
string name;
|
|
|
|
string label;
|
|
|
|
string note;
|
Update to v106r09 release.
byuu says:
Changelog:
- higan, icarus, genius: new manifest syntax (work in progress)
Pretty much only LoROM and HiROM SNES games will load right now, and RAM
will only work right if the save.ram file already exists to pull its
file size from (a temporary cheap hack was used.)
Basically, I'm just getting this out there for evaluation.
One minor errata is that I switched icarus to using “memory/battery” to
indicate battery-backed RAM, whereas genius still uses “memory/volatile”
to indicate non-battery-backed RAM.
I intend to make it “memory/battery” in genius, and have the field
auto-enable when RAM or RTC is selected for type (obviously allowing it
to be unchecked for volatile memory.)
I need to update all 64 production boards, and 25 of 29 generic boards,
to use the new slot syntax; and I also need to update every single core
in higan to use the new manifest game syntax. I want to build out a
generic manifest game parser that all emulation cores will use.
Once I finish this, I'll also need to write a database converter to
update all of my licensed game dumps to the new database syntax.
I also need to write up something for doc.byuu.org explaining the new
manifest game syntax. The manifest board syntax will still be “internal”
and subject to revisions, but once v107 is out, the gamepak manifest
format will be set in stone sans extensions.
2018-03-05 04:34:07 +00:00
|
|
|
vector<Component> components;
|
Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct ListWindow : Window {
|
|
|
|
ListWindow();
|
|
|
|
auto quit() -> void;
|
|
|
|
auto reloadList() -> void;
|
|
|
|
auto updateWindow() -> void;
|
|
|
|
auto newDatabase() -> void;
|
|
|
|
auto loadDatabase(string) -> void;
|
|
|
|
auto saveDatabase(string) -> void;
|
|
|
|
auto appendGame(Game) -> void;
|
|
|
|
auto modifyGame(Game) -> void;
|
|
|
|
auto removeGame() -> void;
|
|
|
|
|
|
|
|
private:
|
|
|
|
bool modified = false;
|
|
|
|
vector<Game> games;
|
|
|
|
string location;
|
|
|
|
|
|
|
|
MenuBar menuBar{this};
|
|
|
|
Menu fileMenu{&menuBar};
|
|
|
|
MenuItem newAction{&fileMenu};
|
|
|
|
MenuItem openAction{&fileMenu};
|
|
|
|
MenuItem saveAction{&fileMenu};
|
|
|
|
MenuItem saveAsAction{&fileMenu};
|
|
|
|
MenuSeparator quitSeparator{&fileMenu};
|
|
|
|
MenuItem quitAction{&fileMenu};
|
|
|
|
Menu helpMenu{&menuBar};
|
|
|
|
MenuItem aboutAction{&helpMenu};
|
|
|
|
|
|
|
|
HorizontalLayout layout{this};
|
|
|
|
TableView gameList{&layout, Size{~0, ~0}};
|
|
|
|
VerticalLayout controlLayout{&layout, Size{80, ~0}};
|
|
|
|
Button appendButton{&controlLayout, Size{~0, 0}};
|
|
|
|
Button modifyButton{&controlLayout, Size{~0, 0}};
|
|
|
|
Button removeButton{&controlLayout, Size{~0, 0}};
|
|
|
|
};
|
|
|
|
|
|
|
|
struct GameWindow : Window {
|
|
|
|
GameWindow();
|
|
|
|
auto show(Game = {}) -> void;
|
|
|
|
auto accept() -> void;
|
|
|
|
auto cancel() -> void;
|
|
|
|
auto reloadList() -> void;
|
|
|
|
auto updateWindow() -> void;
|
Update to v106r09 release.
byuu says:
Changelog:
- higan, icarus, genius: new manifest syntax (work in progress)
Pretty much only LoROM and HiROM SNES games will load right now, and RAM
will only work right if the save.ram file already exists to pull its
file size from (a temporary cheap hack was used.)
Basically, I'm just getting this out there for evaluation.
One minor errata is that I switched icarus to using “memory/battery” to
indicate battery-backed RAM, whereas genius still uses “memory/volatile”
to indicate non-battery-backed RAM.
I intend to make it “memory/battery” in genius, and have the field
auto-enable when RAM or RTC is selected for type (obviously allowing it
to be unchecked for volatile memory.)
I need to update all 64 production boards, and 25 of 29 generic boards,
to use the new slot syntax; and I also need to update every single core
in higan to use the new manifest game syntax. I want to build out a
generic manifest game parser that all emulation cores will use.
Once I finish this, I'll also need to write a database converter to
update all of my licensed game dumps to the new database syntax.
I also need to write up something for doc.byuu.org explaining the new
manifest game syntax. The manifest board syntax will still be “internal”
and subject to revisions, but once v107 is out, the gamepak manifest
format will be set in stone sans extensions.
2018-03-05 04:34:07 +00:00
|
|
|
auto appendComponent(Component) -> void;
|
|
|
|
auto modifyComponent(Component) -> void;
|
|
|
|
auto removeComponent() -> void;
|
Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
bool modified = false;
|
|
|
|
bool create = true;
|
|
|
|
Game game;
|
|
|
|
|
|
|
|
VerticalLayout layout{this};
|
|
|
|
HorizontalLayout hashLayout{&layout, Size{~0, 0}};
|
|
|
|
Label hashLabel{&hashLayout, Size{50, 0}};
|
|
|
|
LineEdit hashEdit{&hashLayout, Size{~0, 0}};
|
|
|
|
HorizontalLayout infoLayout{&layout, Size{~0, 0}};
|
|
|
|
Label regionLabel{&infoLayout, Size{50, 0}};
|
|
|
|
LineEdit regionEdit{&infoLayout, Size{~0, 0}};
|
|
|
|
Label revisionLabel{&infoLayout, Size{0, 0}};
|
|
|
|
LineEdit revisionEdit{&infoLayout, Size{~0, 0}};
|
|
|
|
Label boardLabel{&infoLayout, Size{0, 0}};
|
Update to v106r09 release.
byuu says:
Changelog:
- higan, icarus, genius: new manifest syntax (work in progress)
Pretty much only LoROM and HiROM SNES games will load right now, and RAM
will only work right if the save.ram file already exists to pull its
file size from (a temporary cheap hack was used.)
Basically, I'm just getting this out there for evaluation.
One minor errata is that I switched icarus to using “memory/battery” to
indicate battery-backed RAM, whereas genius still uses “memory/volatile”
to indicate non-battery-backed RAM.
I intend to make it “memory/battery” in genius, and have the field
auto-enable when RAM or RTC is selected for type (obviously allowing it
to be unchecked for volatile memory.)
I need to update all 64 production boards, and 25 of 29 generic boards,
to use the new slot syntax; and I also need to update every single core
in higan to use the new manifest game syntax. I want to build out a
generic manifest game parser that all emulation cores will use.
Once I finish this, I'll also need to write a database converter to
update all of my licensed game dumps to the new database syntax.
I also need to write up something for doc.byuu.org explaining the new
manifest game syntax. The manifest board syntax will still be “internal”
and subject to revisions, but once v107 is out, the gamepak manifest
format will be set in stone sans extensions.
2018-03-05 04:34:07 +00:00
|
|
|
LineEdit boardEdit{&infoLayout, Size{~0, 0}, 0};
|
Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
HorizontalLayout nameLayout{&layout, Size{~0, 0}};
|
|
|
|
Label nameLabel{&nameLayout, Size{50, 0}};
|
|
|
|
LineEdit nameEdit{&nameLayout, Size{~0, 0}};
|
|
|
|
HorizontalLayout labelLayout{&layout, Size{~0, 0}};
|
|
|
|
Label labelLabel{&labelLayout, Size{50, 0}};
|
|
|
|
LineEdit labelEdit{&labelLayout, Size{~0, 0}};
|
|
|
|
HorizontalLayout noteLayout{&layout, Size{~0, 0}};
|
|
|
|
Label noteLabel{¬eLayout, Size{50, 0}};
|
|
|
|
LineEdit noteEdit{¬eLayout, Size{~0, 0}};
|
Update to v106r09 release.
byuu says:
Changelog:
- higan, icarus, genius: new manifest syntax (work in progress)
Pretty much only LoROM and HiROM SNES games will load right now, and RAM
will only work right if the save.ram file already exists to pull its
file size from (a temporary cheap hack was used.)
Basically, I'm just getting this out there for evaluation.
One minor errata is that I switched icarus to using “memory/battery” to
indicate battery-backed RAM, whereas genius still uses “memory/volatile”
to indicate non-battery-backed RAM.
I intend to make it “memory/battery” in genius, and have the field
auto-enable when RAM or RTC is selected for type (obviously allowing it
to be unchecked for volatile memory.)
I need to update all 64 production boards, and 25 of 29 generic boards,
to use the new slot syntax; and I also need to update every single core
in higan to use the new manifest game syntax. I want to build out a
generic manifest game parser that all emulation cores will use.
Once I finish this, I'll also need to write a database converter to
update all of my licensed game dumps to the new database syntax.
I also need to write up something for doc.byuu.org explaining the new
manifest game syntax. The manifest board syntax will still be “internal”
and subject to revisions, but once v107 is out, the gamepak manifest
format will be set in stone sans extensions.
2018-03-05 04:34:07 +00:00
|
|
|
HorizontalLayout lowerLayout{&layout, Size{~0, ~0}};
|
|
|
|
Label componentLabel{&lowerLayout, Size{50, ~0}};
|
|
|
|
TreeView componentTree{&lowerLayout, Size{~0, ~0}};
|
|
|
|
VerticalLayout controlLayout{&lowerLayout, Size{0, ~0}};
|
|
|
|
Button appendMemoryButton{&controlLayout, Size{80, 0}};
|
|
|
|
Button appendOscillatorButton{&controlLayout, Size{80, 0}};
|
|
|
|
Button modifyComponentButton{&controlLayout, Size{80, 0}};
|
|
|
|
Button removeComponentButton{&controlLayout, Size{80, 0}};
|
|
|
|
Widget controlSpacer{&controlLayout, Size{0, ~0}};
|
|
|
|
Button acceptButton{&controlLayout, Size{80, 0}};
|
|
|
|
Button cancelButton{&controlLayout, Size{80, 0}};
|
Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct MemoryWindow : Window {
|
|
|
|
MemoryWindow();
|
|
|
|
auto show(Memory = {}) -> void;
|
|
|
|
auto accept() -> void;
|
|
|
|
auto cancel() -> void;
|
|
|
|
auto updateWindow() -> void;
|
|
|
|
|
|
|
|
private:
|
|
|
|
bool modified = false;
|
|
|
|
bool create = true;
|
|
|
|
Memory memory;
|
|
|
|
|
|
|
|
VerticalLayout layout{this};
|
|
|
|
HorizontalLayout infoLayout{&layout, Size{~0, 0}};
|
Update to v106r09 release.
byuu says:
Changelog:
- higan, icarus, genius: new manifest syntax (work in progress)
Pretty much only LoROM and HiROM SNES games will load right now, and RAM
will only work right if the save.ram file already exists to pull its
file size from (a temporary cheap hack was used.)
Basically, I'm just getting this out there for evaluation.
One minor errata is that I switched icarus to using “memory/battery” to
indicate battery-backed RAM, whereas genius still uses “memory/volatile”
to indicate non-battery-backed RAM.
I intend to make it “memory/battery” in genius, and have the field
auto-enable when RAM or RTC is selected for type (obviously allowing it
to be unchecked for volatile memory.)
I need to update all 64 production boards, and 25 of 29 generic boards,
to use the new slot syntax; and I also need to update every single core
in higan to use the new manifest game syntax. I want to build out a
generic manifest game parser that all emulation cores will use.
Once I finish this, I'll also need to write a database converter to
update all of my licensed game dumps to the new database syntax.
I also need to write up something for doc.byuu.org explaining the new
manifest game syntax. The manifest board syntax will still be “internal”
and subject to revisions, but once v107 is out, the gamepak manifest
format will be set in stone sans extensions.
2018-03-05 04:34:07 +00:00
|
|
|
Label typeLabel{&infoLayout, Size{80, 0}};
|
Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
ComboEdit typeEdit{&infoLayout, Size{~0, 0}};
|
|
|
|
Label sizeLabel{&infoLayout, Size{0, 0}};
|
|
|
|
LineEdit sizeEdit{&infoLayout, Size{~0, 0}};
|
2018-04-08 23:50:42 +00:00
|
|
|
HorizontalLayout contentLayout{&layout, Size{~0, 0}};
|
|
|
|
Label contentLabel{&contentLayout, Size{80, 0}};
|
|
|
|
ComboEdit contentEdit{&contentLayout, Size{~0, 0}};
|
Update to v106r09 release.
byuu says:
Changelog:
- higan, icarus, genius: new manifest syntax (work in progress)
Pretty much only LoROM and HiROM SNES games will load right now, and RAM
will only work right if the save.ram file already exists to pull its
file size from (a temporary cheap hack was used.)
Basically, I'm just getting this out there for evaluation.
One minor errata is that I switched icarus to using “memory/battery” to
indicate battery-backed RAM, whereas genius still uses “memory/volatile”
to indicate non-battery-backed RAM.
I intend to make it “memory/battery” in genius, and have the field
auto-enable when RAM or RTC is selected for type (obviously allowing it
to be unchecked for volatile memory.)
I need to update all 64 production boards, and 25 of 29 generic boards,
to use the new slot syntax; and I also need to update every single core
in higan to use the new manifest game syntax. I want to build out a
generic manifest game parser that all emulation cores will use.
Once I finish this, I'll also need to write a database converter to
update all of my licensed game dumps to the new database syntax.
I also need to write up something for doc.byuu.org explaining the new
manifest game syntax. The manifest board syntax will still be “internal”
and subject to revisions, but once v107 is out, the gamepak manifest
format will be set in stone sans extensions.
2018-03-05 04:34:07 +00:00
|
|
|
HorizontalLayout manufacturerLayout{&layout, Size{~0, 0}};
|
|
|
|
Label manufacturerLabel{&manufacturerLayout, Size{80, 0}};
|
|
|
|
LineEdit manufacturerEdit{&manufacturerLayout, Size{~0, 0}};
|
2018-04-08 23:50:42 +00:00
|
|
|
HorizontalLayout architectureLayout{&layout, Size{~0, 0}};
|
|
|
|
Label architectureLabel{&architectureLayout, Size{80, 0}};
|
|
|
|
LineEdit architectureEdit{&architectureLayout, Size{~0, 0}};
|
|
|
|
HorizontalLayout identifierLayout{&layout, Size{~0, 0}};
|
|
|
|
Label identifierLabel{&identifierLayout, Size{80, 0}};
|
|
|
|
LineEdit identifierEdit{&identifierLayout, Size{~0, 0}};
|
Update to v106r09 release.
byuu says:
Changelog:
- higan, icarus, genius: new manifest syntax (work in progress)
Pretty much only LoROM and HiROM SNES games will load right now, and RAM
will only work right if the save.ram file already exists to pull its
file size from (a temporary cheap hack was used.)
Basically, I'm just getting this out there for evaluation.
One minor errata is that I switched icarus to using “memory/battery” to
indicate battery-backed RAM, whereas genius still uses “memory/volatile”
to indicate non-battery-backed RAM.
I intend to make it “memory/battery” in genius, and have the field
auto-enable when RAM or RTC is selected for type (obviously allowing it
to be unchecked for volatile memory.)
I need to update all 64 production boards, and 25 of 29 generic boards,
to use the new slot syntax; and I also need to update every single core
in higan to use the new manifest game syntax. I want to build out a
generic manifest game parser that all emulation cores will use.
Once I finish this, I'll also need to write a database converter to
update all of my licensed game dumps to the new database syntax.
I also need to write up something for doc.byuu.org explaining the new
manifest game syntax. The manifest board syntax will still be “internal”
and subject to revisions, but once v107 is out, the gamepak manifest
format will be set in stone sans extensions.
2018-03-05 04:34:07 +00:00
|
|
|
HorizontalLayout controlLayout{&layout, Size{~0, 0}};
|
|
|
|
Widget controlSpacer{&controlLayout, Size{~0, 0}};
|
2018-04-15 05:49:53 +00:00
|
|
|
CheckLabel volatileOption{&controlLayout, Size{0, 0}};
|
Update to v106r09 release.
byuu says:
Changelog:
- higan, icarus, genius: new manifest syntax (work in progress)
Pretty much only LoROM and HiROM SNES games will load right now, and RAM
will only work right if the save.ram file already exists to pull its
file size from (a temporary cheap hack was used.)
Basically, I'm just getting this out there for evaluation.
One minor errata is that I switched icarus to using “memory/battery” to
indicate battery-backed RAM, whereas genius still uses “memory/volatile”
to indicate non-battery-backed RAM.
I intend to make it “memory/battery” in genius, and have the field
auto-enable when RAM or RTC is selected for type (obviously allowing it
to be unchecked for volatile memory.)
I need to update all 64 production boards, and 25 of 29 generic boards,
to use the new slot syntax; and I also need to update every single core
in higan to use the new manifest game syntax. I want to build out a
generic manifest game parser that all emulation cores will use.
Once I finish this, I'll also need to write a database converter to
update all of my licensed game dumps to the new database syntax.
I also need to write up something for doc.byuu.org explaining the new
manifest game syntax. The manifest board syntax will still be “internal”
and subject to revisions, but once v107 is out, the gamepak manifest
format will be set in stone sans extensions.
2018-03-05 04:34:07 +00:00
|
|
|
Button acceptButton{&controlLayout, Size{80, 0}};
|
|
|
|
Button cancelButton{&controlLayout, Size{80, 0}};
|
|
|
|
};
|
|
|
|
|
|
|
|
struct OscillatorWindow : Window {
|
|
|
|
OscillatorWindow();
|
|
|
|
auto show(Oscillator = {}) -> void;
|
|
|
|
auto accept() -> void;
|
|
|
|
auto cancel() -> void;
|
|
|
|
auto updateWindow() -> void;
|
|
|
|
|
|
|
|
private:
|
|
|
|
bool modified = false;
|
|
|
|
bool create = true;
|
|
|
|
Oscillator oscillator;
|
|
|
|
|
|
|
|
VerticalLayout layout{this};
|
|
|
|
HorizontalLayout frequencyLayout{&layout, Size{~0, 0}};
|
|
|
|
Label frequencyLabel{&frequencyLayout, Size{60, 0}};
|
|
|
|
LineEdit frequencyEdit{&frequencyLayout, Size{~0, 0}};
|
Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
HorizontalLayout controlLayout{&layout, Size{~0, 0}};
|
Update to v106r09 release.
byuu says:
Changelog:
- higan, icarus, genius: new manifest syntax (work in progress)
Pretty much only LoROM and HiROM SNES games will load right now, and RAM
will only work right if the save.ram file already exists to pull its
file size from (a temporary cheap hack was used.)
Basically, I'm just getting this out there for evaluation.
One minor errata is that I switched icarus to using “memory/battery” to
indicate battery-backed RAM, whereas genius still uses “memory/volatile”
to indicate non-battery-backed RAM.
I intend to make it “memory/battery” in genius, and have the field
auto-enable when RAM or RTC is selected for type (obviously allowing it
to be unchecked for volatile memory.)
I need to update all 64 production boards, and 25 of 29 generic boards,
to use the new slot syntax; and I also need to update every single core
in higan to use the new manifest game syntax. I want to build out a
generic manifest game parser that all emulation cores will use.
Once I finish this, I'll also need to write a database converter to
update all of my licensed game dumps to the new database syntax.
I also need to write up something for doc.byuu.org explaining the new
manifest game syntax. The manifest board syntax will still be “internal”
and subject to revisions, but once v107 is out, the gamepak manifest
format will be set in stone sans extensions.
2018-03-05 04:34:07 +00:00
|
|
|
Widget controlSpacer{&controlLayout, Size{~0, 0}};
|
Update to v106r2 release.
byuu says:
Changelog:
- Super Famicom: added support for loading manifests without embedded
mapping information¹
- genius: initial commit
- various Makefile cleanups
¹: so the idea here is to try and aim for a stable manifest format,
and to allow direct transposition of icarus/genius database entries into
manifest files. The exact mechanics of how this is going to work is
currently in flux, but we'll get there.
For right now, `Super Famicom.sys` gains `boards.bml`, which is the raw
database from my board-editor tool, and higan itself tries to load
`boards.bml`, match an entry to game/board from the game's `manifest.bml`
file, and then transform it into the format currently used by higan. It
does this only when the game's `manifest.bml` file lacks a board node.
When such a board node exists, it works as previous versions of higan
did.
The only incompatible change right now is information/title is now
located at game/label. I may transition window title display to just use
the filenames instead.
Longer term, some thought is going to need to go into the format of the
`boards.bml` database itself, and at which point in the process I should
be transforming things.
Give it time, we'll refine this into something nicer.
2018-02-01 08:20:37 +00:00
|
|
|
Button acceptButton{&controlLayout, Size{80, 0}};
|
|
|
|
Button cancelButton{&controlLayout, Size{80, 0}};
|
|
|
|
};
|