Discussion:
Bitsy Rip preview
Add Reply
John Brooks
2017-08-10 17:22:44 UTC
Reply
Permalink
Raw Message
Here is alpha of Bitsy Rip 0.4, my bit level disk imager (like EDD card) but no EDD card needed. Just GS+4MB RAM.

http://www.brutaldeluxe.fr/public/jb/

-JB
@JBrooksBSI
Oliver Schmidt
2017-08-11 08:36:37 UTC
Reply
Permalink
Raw Message
Hi John,
Post by John Brooks
Here is alpha of Bitsy Rip 0.4, my bit level disk imager (like EDD card)
but no EDD card needed. Just GS+4MB RAM.
Cool!

Is this supposed to be/become an open source project/prduct? If yes, do you
plan to make use of a public version control service like GitHub?

Regards,
Oliver
John Brooks
2017-08-11 18:02:50 UTC
Reply
Permalink
Raw Message
Post by Oliver Schmidt
Hi John,
Post by John Brooks
Here is alpha of Bitsy Rip 0.4, my bit level disk imager (like EDD card)
but no EDD card needed. Just GS+4MB RAM.
Cool!
Is this supposed to be/become an open source project/prduct? If yes, do you
plan to make use of a public version control service like GitHub?
Regards,
Oliver
Possibly. Right now Bitsy Rip is a proof-of-concept and has a ways to go to become a full product.

Since this project has to run on physical GS hardware and is written on the GS using Merlin16, it's currently difficult/time-consuming to use GitHub during development.

Please contact me here, or on twitter: @JBrooksBSI if you'd like to collaborate on making Bitsy Rip a full product.

-JB
Oliver Schmidt
2017-08-12 23:46:02 UTC
Reply
Permalink
Raw Message
Hi John,
Post by John Brooks
Since this project has to run on physical GS hardware and is written on
the GS using Merlin16, it's currently difficult/time-consuming to use
GitHub during development.
I must admit that I'm surprised. I thought you were into a high speed
serial remote ProDOS block driver for the GS. So I'd think it would be easy
for you to develop on the GS and still have the source files physically
located on a machine with "GitHub access". Anyhow I see the point you want
to make.
Post by John Brooks
collaborate on making Bitsy Rip a full product.
That's from my perspective the very beauty of GitHub: Most of the time
someone doesn't intend to work on a project right away. They start looking
at the source. Then make maybe small modifications to it. They send GitHub
pull requests with those changes. Still no commitment, still not being a
project member. Maybe they like how their pull requests are treated and
they start to contribute regulary. Small steps...

Just my two cents,
Oliver
John Brooks
2017-08-13 02:04:58 UTC
Reply
Permalink
Raw Message
Post by Oliver Schmidt
Hi John,
Post by John Brooks
Since this project has to run on physical GS hardware and is written on
the GS using Merlin16, it's currently difficult/time-consuming to use
GitHub during development.
I must admit that I'm surprised. I thought you were into a high speed
serial remote ProDOS block driver for the GS. So I'd think it would be easy
for you to develop on the GS and still have the source files physically
located on a machine with "GitHub access". Anyhow I see the point you want
to make.
Post by John Brooks
collaborate on making Bitsy Rip a full product.
That's from my perspective the very beauty of GitHub: Most of the time
someone doesn't intend to work on a project right away. They start looking
at the source. Then make maybe small modifications to it. They send GitHub
pull requests with those changes. Still no commitment, still not being a
project member. Maybe they like how their pull requests are treated and
they start to contribute regulary. Small steps...
Just my two cents,
Oliver
I must admit that I'm surprised. I thought you were into a high speed
serial remote ProDOS block driver for the GS.
Correct, the xHD server provides two 32MB ProDOS volumes which are accessible by the GS. Unfortunately, Github doesn't know anything about ProDOS file structure or limitations. Git is really designed for unix file systems

With enough work, some of these issues like linefeed vs carriage-return line endings, ascii high bit set vs clear, file naming restrictions, and getting files into & out of the ProDOS disk images correctly could be addressed if someone wants to take that work on.
Post by Oliver Schmidt
That's from my perspective the very beauty of GitHub: Most of the time
someone doesn't intend to work on a project right away.
Agreed, and I hope that eventually Bitsy Rip can get to that point. Right now, however, the project is in the 'heavy lifting' stage, not the 'small steps' stage. Putting in the missing foundation machinery will require expertise and coordination as there are tight timing and memory restrictions at various places in the code which will affect the design and implementation of the missing subsystems.

Explaining to and coordinating with casual developers who may not actually contribute would likely reduce my limited 'hobby' time doing heavy-lifting on ProDOS and/or Bitsy Rip and slow progress of getting those projects out to the community.

Once the project(s) reach 'usable' status, then open-sourcing becomes both educational for the community to browse, as well as enabling 'small step' community contributions.

I wish there was an easier way, but I don't know what it is. These are valuable products but with a lot of complex R&D. I guess if they were less difficult, they likely would have been done by someone long ago.

-JB
@JBrooksBSI
Oliver Schmidt
2017-08-13 13:59:33 UTC
Reply
Permalink
Raw Message
Hi John,
Post by Oliver Schmidt
I must admit that I'm surprised. I thought you were into a high speed
serial remote ProDOS block driver for the GS.
With enough work, some of these issues like linefeed vs carriage-return lin=
e endings, ascii high bit set vs clear, file naming restrictions, and getti=
ng files into & out of the ProDOS disk images correctly could be addressed =
if someone wants to take that work on.
I personally would rather invest into switching to cross dev in the
first place ;-)
Post by Oliver Schmidt
That's from my perspective the very beauty of GitHub: Most of the time
someone doesn't intend to work on a project right away.
Agreed, and I hope that eventually Bitsy Rip can get to that point. Right n=
ow, however, the project is in the 'heavy lifting' stage, not the 'small st=
eps' stage.
[...]
Once the project(s) reach 'usable' status, then open-sourcing becomes both =
educational for the community to browse, as well as enabling 'small step' c=
ommunity contributions.
[...]

Thanks for detailed explanation :-) I see now.
I wish there was an easier way, but I don't know what it is. These are valu=
able products but with a lot of complex R&D. I guess if they were less diff=
icult, they likely would have been done by someone long ago.
;-)

Regards,
Oliver
John Brooks
2017-08-13 21:25:14 UTC
Reply
Permalink
Raw Message
Post by Oliver Schmidt
Hi John,
Post by Oliver Schmidt
I must admit that I'm surprised. I thought you were into a high speed
serial remote ProDOS block driver for the GS.
With enough work, some of these issues like linefeed vs carriage-return lin=
e endings, ascii high bit set vs clear, file naming restrictions, and getti=
ng files into & out of the ProDOS disk images correctly could be addressed =
if someone wants to take that work on.
I personally would rather invest into switching to cross dev in the
first place ;-)
Post by Oliver Schmidt
That's from my perspective the very beauty of GitHub: Most of the time
someone doesn't intend to work on a project right away.
Agreed, and I hope that eventually Bitsy Rip can get to that point. Right n=
ow, however, the project is in the 'heavy lifting' stage, not the 'small st=
eps' stage.
[...]
Once the project(s) reach 'usable' status, then open-sourcing becomes both =
educational for the community to browse, as well as enabling 'small step' c=
ommunity contributions.
[...]
Thanks for detailed explanation :-) I see now.
I wish there was an easier way, but I don't know what it is. These are valu=
able products but with a lot of complex R&D. I guess if they were less diff=
icult, they likely would have been done by someone long ago.
;-)
Regards,
Oliver
I personally would rather invest into switching to cross dev in the
first place ;-)
Yes, I spent several months creating a cross-dev toolchain in 2015 using Xcode with Merlin32 and MPW AsmIIGS, and then creating the xHD client and server components. Once I get xHD added to ProDOS 2.5 and out to the community, I'd like to move my cross-dev toolchain from Xcode to Visual Studio Code. VS Code is a nice cross-platform open-source IDE and is more easily extendable for cross-development than Xcode.

If you would like to help improve the cross-dev toolchain, I can put you in contact with other Apple II devs who are working in that area now.

-JB
@JBrooksBSI
Oliver Schmidt
2017-08-14 19:17:43 UTC
Reply
Permalink
Raw Message
Hi John,
If you would like to help improve the cross-dev toolchain, I can put you in=
contact with other Apple II devs who are working in that area now.
Given that I both maintain an Apple II cross dev tool chain (cc65) and
are interested in the topic I'd appreciate to at least learn where
current efforts are heading to - and maybe add something to it.

Regards,
Oliver
Egan Ford
2017-08-14 23:05:30 UTC
Reply
Permalink
Raw Message
Post by Oliver Schmidt
Hi John,
If you would like to help improve the cross-dev toolchain, I can put you in=
contact with other Apple II devs who are working in that area now.
Given that I both maintain an Apple II cross dev tool chain (cc65) and
are interested in the topic I'd appreciate to at least learn where
current efforts are heading to - and maybe add something to it.
I'd also like to know what that state-of-the-art is in cross-dev for the
IIe and IIgs. And what others are doing in this area, including
automated test and performance profiling.

For years I have been using ca65 for the IIe and asl (Macro Assembler AS
V1.42) for the IIgs. I also use git, vim, and make. For testing I use
Virtual ][ because it can be fully automated with AppleScript, so "make
test" is easy.

For profiling code performance I've been using open source 6502 and
65816 cores with thin wrappers that provide instruction usage, ticks,
and other counters that I trigger with macros. Clearly only useful for
testing pure 6502/65816 code.

I do not have any nice way to automate IIgs testing. However I really
do very little with the IIgs.

Loading...